German Jet

Я бы мог сейчас начать перечислять длинный список преимуществ Python перед остальными языками и разжечь лютый холивар, но не буду. Самое главное преимущество Python перед другими языками - это предельно простое взаимодействие между кодом на Python и кодом на C\C++. Это даёт возможность писать простую и изящную логику в скриптах, а тяжёлые вычисления выносить в нативный код.

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

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

Если охота не отбилась, то нужно определиться со сферой - энтерпрайз (c#, java), мобайл (java, swift, kotlin и т.д.), web-разработка (а там либо фронтенд - html, css, туча js-фреймворков, либо бэкенд - php, python, ruby, node.js и также туча фреймворков). А может и вовсе администрирование серверов, devops, big data, машинное обучение, статистика, системная аналитика, gamedev и пр. По каждой нише свой огромный технологический стек, которого хватит на годы только изучения...потом годы вырастания из джуниора, потом годы закрепления в мидлах, а потом до свидания, потому что 25-летних синьоров на улице очередь стоит))

От того, что ты взял первые 3 языка из топ-2017 толку мало (java куда дел тогда?). На полноценное освоение (прежде чем к полноценной работе приступать), нужно минимум 2 года потратить активного набивания шишек (и не час-полтора после работы, а с утра и до вечера). Пройди курс "основы программирования на языке X", и сразу двигайся по выбранной нише, нет смысла залипать на C/C++ если нет конкретной цели их приложить к чему-либо.

Если тебе "для души" - то пробуй всё, на что глаз ляжет, и выбирай на практике, а не по советам с форумов. Если нужно поскорее на работу выйти, основной спрос на джуниоров идет в java, web (как правило, вёрстка, php и cms), 1С. На фрилансе главенствует web-разработка, в основном js на фронтенде и php на серверной части. Чтобы понять, за что браться, достаточно открыть хх.ру, биржи фриланса и изучить спрос.

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

Пофантазируем. Предположим, что тебя не поставили на телефон, а сразу разрешили что-то программировать. Предположим, что тебе дают задачу "у клиента Х не проводится документ, выдает ошибку - нужно исправить". Ты лезешь в код и находишь, что ошибка из-за незаполненного реквизита. Ок, ты с чувством выполненного долга удаляешь непонятную проверку и сдаешь работу. На следующий день прибегает взмыленный начальник: "Ты что натворил? У клиента полетели все отчеты и период не закрывается!!!" - оказывается логика одной из подсистем крутится вокруг того, что тот реквизит ВСЕГДА должен быть заполнен и тебе было нужно не комментировать ошибку, а вывести сообщение пользователю, что он забыл внести важное значение...

В 2004 году, когда меня зеленым новичком взяли в одну контору программистом с нулевыми знаниями программ моей фирмы, языка программирования (FoxPro) и основ экономики/бухгалтерии (включая терминологию), меня тоже изначально посадили на телефон оператором службы поддержки. Классический рабочий день - принимал звонок, бегал в мыле между сотрудников пытаясь узнать решение проблемы, лазил в листинги в попытках разобрать логику кода..., отзванивался клиенту и решал его проблему. В результате за два месяца уже знал всю терминологию, знал особенности всех наших программ и довольно неплохо программировал на FoxPro. При этом я настолько хорошо себя зарекомендовал, что мне полностью доверили проект перевода наших российских бюджетников на новый план счетов (согласно приказа Минфина РФ от 26.08.2004 № 70н). А через год я уже по заказу одной из киевских газет написал с нуля программу для учета распространения тиража печатной продукции.

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

1) jquery и vue.js совершенно разные вещи и решают они совершенно разные задачи. jquery создан для кросcбраузерной работы с DOM. Vue.js и подобные созданы для работы с данными.

2) Не факт. Для создания модальных окон, лайтбоксов, слайдеров, вам может понадобиться там и jquery, т.к. аналоги jquery плагинов не всегда есть на нативном javascript. + Готовых компонентов для vue.js не так уж и много, по сравнению с react или angular. Но их кол-во растёт

3) А что вам даёт jquery, кроме добавления нескольких плагинов? По сути, ничего такого vue вам не даст.

4) Очень многое. Разделение всего и вся на компоненты. Которые можно переиспользовать в разных частях сайта не думая о дублировании стилей, js логики и т.п.

5) Да во всех можно использовать, будь то блог или интернет магазин.

6) Если проект с нуля, то можно использовать vue.js. НО!!! Для начала, вам, его нужно изучить и достаточно хорошо!!! А так же, скооперироваться со своей командой. Дизайнерами и серверными разработчиками.

7) Лично я, пока не знаю его на достаточно хорошем уровне, но уже могу легко написать на нём блог и прикрутить node.js + express + mongodb для обработки данных на сервере. Бесконечная подгрузка постов, фильтрация данных без перезагрузки и триллион всего.

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

Я проходил курс тут. Он на английском, но достаточно понятный.

P.S. jQuery можно использовать вместе с vue.js без всяких проблем

1. это разные вещи
2. если не завязан на компоненты, использующие jquery (хотя тот же bootstrap есть отвязанный)
3. ничего, так как в лендингах обычно немного логики, разница ощущается при росте количества связей
4. смотря что за страницы, см. выше
5. single page applications, rich internet appalications
6. когда появляется input/блок содержимое которого связано с какими-то данными, меняющимися в другом inputе/блоке
7. тысячи их. например таблица с фильтром целиком на клиенте.

save(update_fields=['field'])

например можно не трогая фронтенд сменить фреймворк или даже язык.

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

Ну например выбрать 10 новостей в нужном формате
делаем GET запрос

Обычно делают POST-запрос, и не в формате адресной строки (GET-параметров), а отправляется так же, запрос в формате JSON. Обратите внимание на ключевое слово "обычно", т.е. не всегда.

Применяется такой подход к проектированию?

Это скорее подход к разработке, уровня "клиент-сервер", и/или REST API.

И может есть готовые решения о которых можно почитать.

Не совсем понятно, какое именно готовое решение Вы хотите получить. HTTP-клиенты и обработка JSON-данных, встроена во многие языки, или реализована в виде готовых библиотек.

Или есть какие то существенные минусы о которых я не догадываюсь?

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

Насколько я понимаю, Вы хотите обернуть РСУБД (SQL-БД), работающую через (unix-)сокет, в более примитивные API, выдающие ответы в формате JSON? А чем Вас ответ в формате "SQL result resource" не устроил? :) При использовании РСУБД (и не только) Вы так же можете сменить и шаблонизатор, и фреймворк и язык и всё остальное, а необходимый функционал написать на уровне самой БД, в виде хранимых функций/процедур, без дополнительных, ненужных цепочек передачи данных.