Евгений Ромашкан

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

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

просьба дать определение -- примитивный способ выявить способность излагать мысль/мыслить просто

Если вы этот бред говорили на собеседовании - ничего удивительного. ООП это не Гумилев, его не надо цитировать.

По сути ваш вопрос касается только одной темы - маркетинга.

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

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

Так что однозначных рецептов дать нельзя. Смотреть нужно в сторону маркетинга и просто здравого смысла. Например, A/B тестирование - это технология именно маркетинга, а не дизайна или программирования (и порой она даёт очень необычные результаты).

Вспоминая прошлое, могу сказать, что в начале 2000х была мода делать всякие свисто-перделки на своих сайтах, всякие анимации, выезжающие меню, выпрыгивающих персонажей, падающий снег и т.д. Авторы таких творений почему-то думали, что это безумно круто и должно нравиться всем. По факту это нравилось только авторам этих поделок. Большинству же важно наполнение сайта контентом, удобство восприятия контента. А всякие типа вау-эффекты на самом деле только отвлекают и на них вырабатывается аналог рекламной слепоты (но не у всех, некоторых просто бесит). Так что если лендинг посвящен, скажем, пылесосам, то сделайте ознакомление удобным - например, обзор продукта в 3D. Это будет лучший вау-эффект в данной конкретной тематике.

По словам Макарова, там много что надо будет переделать, но не так много, как при переходе с 1-й на вторую. Изначально же 3.0 задумывалась как 2.1 и должна была быть обратная совместимость. Но в процессе попили столько, что с совместимостью пришлось бы добавить костыльность. Поэтому не ломая сементик версионирование решили сделать 3.0. При этом много что осталось не тронуто. Так что переход будет возможен, но явно не будет простым.
Вот Макаров выступал про php и про framework-и и в конце рассказал про ошибки yii2 и про yii3:
https://youtu.be/WzLXWI2rD3Y?t=33m26s
Решать "ждать" или "делать на 2.x" надо исходя из проекта. Что это будет? Какой стек будет использоваться? и т.д. Возможно Вам вообще 3.0 не нужен. Учитывая, что 1.х до сих пор поддерживается и комиты не редки, можно ожидать того же с 2.x Так что я бы сказал, что вероятно не стоит сидеть и ждать. И скорее всего не стоит даже строить планы на переход на 3.0 Чем текущая не устраивает?

На фрилансе.
На хедхантере.

Магистратура === научная деятельность
Магистратура в ИТ ===
- научная деятельность
- хорошее знание математики
- отличное знание и любовь к своей области математики
- опыт пром разработки от 5 лет
- нахождение в области ИТ от 10
- работа напрямую связанная с внедрением результатов вашей научной деятельности

Никакая магистратура вас не готовит к "работе"

Так вот, для меня, - все AJAX запросы это API

В этом ваша ошибка. Аякс это далеко не апи! Аякс это всего лишь асинхронный запрос к серверу. А что там на сервере - это другое дело.

Апи можно дергать как Аяксом, так и curl и другими методами.

Есть неплохой репозиторий который содержит приложение из "реального мира разработки", одна спека - множество реализаций, Vue там тоже есть:
https://github.com/gothinkster/realworld

Могу дать такие советы, как вижу это я.

Разделить приложение на три уровня:
1) Presentation - уровень представления, при помощи которого пользователь взаимодействует с приложением;
2) Business Logic - слой бизнес-логики;
3) Persistence - слой где хранятся данные, но обычно это реляционная БД.

Если это настольное приложение, то слой Presentation разбей на три компонента согласно паттерну MVP (Model-View-Presenter), если это классическое веб-приложение, то паттерну MVC (Model-View-Controller).

Слой бизнес-логики реализуй согласно паттерну Transaction Script, ну либо паттерну Модель предметной области, где для начала будет анемичная модель (anemic model), которая полностью совпадает со схемой БД, а логику храни в сервисах. Далее когда наберешься скиллов, то можешь пробовать из анемичной модели предметной области сделать богатую (rich model), для этого можешь обратить внимание на методологию DDD (Domain-Driven-Design).

Ну и слой хранения, тут пока тупо через средства ORM...

Ну примерно так, ничего нового и волшебного тут нету.

Прекратить копипастить и начать писать код самостоятельно.

Станок_id действие_id время.
1_станок включился  00:00
1_станок выключился 00:17

Дальше сам.

Отсутствует метод setSubscription, вызов в 97 строке файла site.ru/classes/payment.php

Гм... Как-то размыто, есть вот например само программирование, и есть ООП это его часть, очень важная часть, это всё, что я знаю о том, что такое ООП, если так можно сказать.

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

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

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

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

Очень пугает что вы видимо даже не пытались гуглить. Даже при самом простом запросе "ооп python" можно найти кучу статей по примеру этой - https://python-scripts.com/object-oriented-program... . Из личного опыта могу только посоветовать обязательно закрепить всё практическими упражнениями.

Тут есть очень простое объяснение:

1) Это Unity, которая сильно снижает планку зп по рынку.
2) Студенты. Майкрософт хорошо лоббирует .net в универах, поэтому большая часть студентов (которые готовы работать за еду), идут со знанием .net
3) В США большая часть .net работы — это компании в области гос/финтех-сектора. У нас же по историческим причинам, в этом секторе основной игрок Java. Следовательно и деньги в .net не идут.
4) .Net — дорогой стек, поэтому все стартапы, которые вынуждены большой зп конкурировать с более «стабильными» компаниями за разработчиков, выбирают python/java/php, а не .net. Хостинг на .net — крайне разорителен (сейчас, конечно, появился .net core — но он еще слишком молод, чтобы поменять ситуацию).
5) .net часто используется во всяких тендерных проектах, где руководство использует принцип «совка». Разработчик должен быть голодным и «уставшим».

___

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

Реально открываешь вакансии, там middle .net разраб — 90-120к тысяч. Хотя проекты такой же сложности на Java — идут уже 120-150к. В общем, так сложилось, что .net платят меньше, и работодатели не шибко хотят поднимать эту планку.

Привет:

1) Пойти работать QA-Лидом в крупную компанию, банк. Фактически завязываться на митинги и работу с персоналом. Можно получать хорошие деньги, почему нет.

2) Настраивать изначально QA для стартапов. Связку test-rail/jenkins/тесты/хвосты на стороне АПИ сделать с нуля достаточно сложно, поэтому за это готовы платить хорошие деньги (но не долго)
2.1) Заниматься фрилансом, открыть свою фирму и делать под заказ то, что описано в пункте 2.

3) Переходить в менеджеры и управление. И потом уже расти до более жирных должностей. Не видел, чтобы QA назначали на CTO, все же глубина знаний требуется совершенно разная.

4) Уходить CTO в непрофильные компании(не айтишные), где на фоне сисов и эникеев, вы будете крутым, грамотным спецом.

5) Открыть свою школу тестеров, разъезжать на гибридном лексусе и рассказывать о том, как круто быть тестером (кто понял аналогию, ставим лайк)