Vicom

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

Будьте конкретны:
- "Моя цель на ближайшие 6 месяцев - вырасти до позиции XXX в текущей компании". И далее:
- "Что мне нужно сделать для того, чтобы в течение 6 месяцев в моей компании вырасти до XXX ?"

С этим уже можно обратиться к людям, обладающим достаточной компетенцией в помощи вам с ответом на этот вопрос: "Для того, чтобы в нашей компании стать XXX, нужно знать ЭТО и уметь ТО".

- "Что мне нужно для того, чтобы узнать ЭТО и научиться делать ТО ?". Cоставляете план действий (разбиваете необходимые шаги на месяцы, недели, дни) с дежурными сроками (для проверки запланированного и достигнутого, внесения в связи с этим необходимых корректировок и т.п.) - и вперед.

Но все начинается с конкретики:
- "...хочется максимально эффективно развивать себя...". Что конкретно значит (для вас) "максимально эффективно"? По каким критериям вы будете определять, эффективно вы развиваетесь или нет? Количество прочитанных книг? Сложность решаемых задач? Что конкретно?
- "...чтобы стать не только полноценным девом...". Что конкретно значит (для вас) "полноценный дев"? Как вы поймете, что стали "полноценным девом"? Вы добьетесь определенной должности? Будете зарабатывать определенную сумму денег? Что конкретно?

Успехов.

Начните отсюда:

paperjs.org
https://greensock.com/tweenmax

Ну а если анимация очень простая то вообще на CSS:
https://daneden.github.io/animate.css/

И начните изучение:
https://habrahabr.ru/post/135816/
https://habrahabr.ru/company/odnoklassniki/blog/158917/
https://habrahabr.ru/company/nordavind/blog/209462/

я останавливаюсь на простой ошибке и сижу над ней полдня, как это исправить?

Варианта 3:
1. Вы не понимаете английский язык
2. Вы не понимаете терминов, выводящихся в ошибке из-за слабых знаний языка.
3. Вы не понимаете логики работы своего же кода.
Нужно устранять эти "пробелы" через понимание и запоминание.

Вот памятка о том, как лучше делать, чтобы не путаться.

Нужен спец по ООП и UML, который работал в своё время с MVC!

Наблюдаю тут несостыковку. Обычно когда говорят о UML - вот все эти вещи вроде контроллеров и т.д. расписываются на уровне компонентов. В UML обычно описывают только доменную логику, то есть то что важно.

В любом случае в Yii такие подходы работают очень плохо. Там вы не ООП делаете а базу данных проектируете (это чуть разные вещи), и все остальное уже от этого отталкивается.

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

p.s. забудьте об этой бесполезной для бэкэнда аббревиатуре MVC. Пока вы "проектируете контроллеры" - толку от него нет (ну то есть пока у вас логика работы с данными в контроллере).

Читаю GOF, Зандстру и т.п.

Почитайте Applying UML and Patterns - Craig Larman - замечательная книга. Еще дядю боба можете почитать (про SOLID). Если вас интересуют темы проектирования то это будет полезно. Еще раз уж заговорили о проектировании логики предметной области - Эрик Эванса - Предметно ориентированное проектирование.

Задача 1

1) композиция всегда лучше наследования
2) наследование нужно для того что бы организовать подтипы. Если у вас есть сущности которые по своей природе требуют наследование - то можно. А так - лучше его избегать. ООП как бы не про наследование вообще.
3) интерфейсы нужны для того что бы организовать инверсию зависимости и/или полиморфизм подтипов. У Лармана можете почитать про protected variations для того что бы понять зачем их юзать.

Задача 2

В UML отношения между типами очень легко и просто отображаются:

- Base[classname] - wrappers для обеспечения ровного обновления самого Yii в дальнейшем, не обращайте внимания.

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

для такой простой задачи я пилю UML исключительно в целях тренинга

Пока это выглядит как впустую потраченное время, поскольку вы выбрали не лучший инструмент (yii) что бы тренироваться проектировать ОО решения.

Я рекомендовал бы вам:

- Разобраться что такое ООП на самом деле (это не про инкапсуляцию. полиморфизм и уже тем более не про наследование ибо все это было еще до ООП и все это кроме наследования является важными принципами структурного программирования). Это про сокрытие состояния и управление зависимостями (связанность, coupling & coheasion у Лармана)
- Взять более подходящие для проектирования ОО решений инструменты (какой-нибудь модный нынче Laravel + Doctrine2)
- если хотите продолжать баловатся с Yii сделайте так, что бы логика предметной области ничегошеньки не знала о Yii, тогда вообще не нужно будет заниматься этими Base* классами. Почитайте про Row Data Gateway (это по сути предшевственник ActiveRecord) а именно как оно использовалось в контексте модели предметной области.

Есть ли под это паттерн?

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

Оригинальная книга по GoF в этом плане так себе, сейчас лучше смотреть в сторону Head First Design Patterns Ну и помимо паттернов нужно разобраться с общими принципами такими как закон деметры, SOLID, GRASP и т.д. Тогда понимание всего будет более системным.

Язык Ada был разработан по заказу Министерства Обороны США с требованием доказательного соответствия очень четкой и обширной спецификации. Существует строгая сертификация компиляторов на предмет проверок фазы компиляции отчего коммерческих компиляторов немного и они дорогие. В 1991 МинОбороныСША сделало Ada единственным и обязательным языком для своих проектов. В 1997 ограничение снято но унаследована огромная база кода. В гражданской авиации например AIMS - мозги Boeing 777, Canadian Automated Air Traffic System, UnitedKingdom Interim Future Area Control Tools Support (iFACTS).

Мне 20 лет, живу отдельно от родителей, зарабатываю фрилансом. Самое важное - организовать свой день.

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

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

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

8 часов подряд кодить каждый день... Вы серьёзно? На этой неделе мои результаты такие: воскресенье - 12 часов кодинга, понедельник - 8, вторник - 8, среда - 6, четверг - 4, пятница - 3, суббота (сегодня) - нет ни малейшего желания, но очень надо хотя бы пару часов... Вы просто перегорите. Настраивайтесь на 4, максимум на 6 часов кодинга в день. Остальное время можно заполнить чтением документаций, проработкой прототипов на бумаге, обсуждениями с коллегами и боссом.

Если ситуация требует 8-16 часов кодинга подряд (такое, увы, бывает), то меня спасают две вещи:
1) Сериалы. Второй монитор, второй ПК, планшет или даже смартфон вам в помощь. Берёте сериал, который УЖЕ смотрели и включаете. Он должен быть интересный, но уже знакомый, это два обязательных требования. Так он не будет отвлекать от работы (сюжет же уже знаком, а половину реплик вы можете произнести вместо актёров), но создаст иллюзию отдыха. В моём случае можно всё привести к такому выражению: 60 минут кодинга = 80 минут кодинга под сериал. НО! Так я могу выдерживать 12-16 часов без особых усилий. Что в итоге даёт больше результата, чем 6-8 часов чистого кодига после которых я просто убитый на пару дней.
2) Кофеин. Обычный кофеин. Кофе я не пью, а энергетики слишком дорогие для регулярного применения. Есть замечательная альтернатива - Кофеин-бензоат натрия. ~30рублей в аптеке за 6 таблеток. Максимальная разовая доза - 6 таблеток, она же 300мг кофеина. 1-2-3 таблетки мой организм может не заметить, а при шести я начинаю разговаривать сам с собой. Грань очень тонкая, но при правильной дозировке получается неплохой boost к производительности. Внимание! Кофеин может повышать давление и пульс, а также имеет ряд побочных эффектов. Передозировка может убить. Я не несу ответственности за последствия приёма кофеина.

Смесь кофеина и прогулки (зима, 3 часа ночи, -20C) может породить тонну гениальных идей, увы, лишь 1 из сотни имеет шанс на успех в реальном мире.

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

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

Непосредственно программирование (как и дизайн) идёт легче, если есть план и схемы. В моём случае при работе над back-end у меня 70% времени уходит на проектирование и проработку мелочей на бумаге, лишь 30% времени это сам кодинг. При работе с фронт-эндом я где-то 60-70% времени работаю, а 30-40% проектирую. Я так понимаю, вас не заставляют именно кодить 8 часов. Вас заставляют 8 часов сидеть на рабочем месте. Вот и прикиньте, что из них лишь где-то 3-4 часа будут самим кодингом. Хотя... Если работы очень много, вы не единственный кодер в конторе и есть более опытные, которые и берут на себя всё проектирование... ух... тогда остаётся только монотонно стучать по клаве...

Ещё очень важный момент. ОБЯЗАТЕЛЬНО ОТДЫХАЙТЕ! В выходные не должно быть ни единой мысли о работе, после работы займитесь хобби, уберитесь дома, погуляйте, сходите в спорт зал, почитайте книгу, посмотрите кино, поспите в конце-концов. Никакой работы за пределами рабочего места. Этот трюк заставит мозг ассоциировать рабочее место с рабочим процессом, а значит уже не нужно будет самому его мотивировать работать. Это работает крайне просто. Если вы видите очень красивую девушку да ещё и без одежды, то кое-что что происходит с одним очень важным органом и мозг начинает работать совершенно иначе. И вот теперь в поле зрения попадает ваше кресло и ваш рабочий комп, мозг пробегается по ассоциациям и понимает, что надо работать. В паре с состоянием вынужденной необходимости всё сработает на ура.

Перерывы - спорный момент. Мне проще проработать, например, 6 часов без перерывов (только если на отойти до туалета или до кухни, чтобы налить воды и стащить печеньку), чем 6-8 с перерывами. Я очень много времени и сил трачу на переключение с одного вида деятельности на другой.

По поводу еды. В момент приёма и пищи и где-то следующий час я способен только читать и смотреть, но никак не творить.

v4-alpha.getbootstrap.com/getting-started/flexbox кажется по этому поводу скоро мучиться не придется)

Disclaimer: у меня нет опыта командной работы именно в Python / Django. Но есть опыт одиночной работы в этом стеке, и опыт командной работы в других технологиях (J2EE).

При следующих условиях:

• Есть опыт в веб - разработке
  
• Команда маленькая (2-3 человека) и уже слаженная
  
• Приличный английский (чтобы не было сложностей с чтением документации)
  
• Знание Python (хотя бы на промежуточном уровне)
  
• Понимание принципов ООП и базовых структур данных
  
• Имеется достаточное время на разработку, включая время требуемое на обучение технологии и приобретение начального опыта
  
• И главное, большое желание осваивать новое, и понимание, что это может потребовать работы сверхурочно, по крайней мере вначале
  

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

• Легче найти компетентных разработчиков - пусть их меньше в Python, но средний уровень у них будет выше, чем в Php. Весьма вероятно также, что потребуется меньше разработчиков в команду.
  
• Код гораздо лучше масштабируется, за счет средств как Python, так и Django
  
• При правильной работе и развитии проекта, меньше шансов что он превратится в неподдерживаемую кашу. С кодом легче будет работать, отлаживать, добавлять новый функционал
  
• Весьма вероятно, что багов и прочих косяков будет существенно меньше
  

Вы тоже получите немало - сможете в рабочие часы вырасти как разработчик, и освоить современный язык / фреймворк / стек.

Бояться разных проблем и граблей я бы не стал. Сейчас на Stack Overflow можно найти ответ практически на любой вопрос или возникшую проблему. Опыт быстро наберете в процессе, если работать на совесть. Есть прекрасные книги, где обсуждаются лучшие практики, тонкие места, и др. По личному опыту могу сказать - когда "наберете скорость", даже в одиночку можно работать в Python / Django очень быстро. У меня, правда, был уже большой опыт в других языках (в том числе функциональных), это сильно помогало с архитектурой. Я не сомневаюсь, что в Python при желании можно писать такой же код, как и в Php. Поэтому одним из самых больших препятствий может стать необходимость менять стиль мышления и отказываться от шаблонов, привычных по Php.

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

Событийная модель помогает строить слабосвязанную систему. Пример из жизни. Я сейчас работаю над SAAS платформой. Компания покупает учетку и выбирает за какие модули платить. Есть модули учета, проверок, для кадровиков и т.д. Модули должны взаимодействовать между собой, но любого модуля может не быть.

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

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

Это на самом деле очень удобно. Но есть и негативная сторона: из-за слабой связаности усложняется навигация по коду. Что бы узнать, где есть обработчики приходится пользоваться поиском по имени события. Но это малая цена за гибкость, которую дают события.