German Jet

Мне кажется в вашем случае будет проще написать REST api на Django и админку на angular, react, vue ...

просто заточить под свои нужды

Нет, не просто.
Нет, туда нельзя пускать пользователей.
Да, админку проще написать с 0

Чем большее количество граблей соберете и решите - тем больше опыта получите

Программист 1С это человек оркестр, умеет программировать (с точки зрения обычных программистов очень своеобразным образом), знает бухучёт, документооборот, бизнеспроцессы, консультировать пользователей по работе программ и по бухучёту (например получить задание - настроить расчёт НДФЛ, потратить подня - высянить что это уже реализовано и внушить это заказчику, обучить заказчика этим пользоваться)
И да, это всё в одиночку...никаких вам аналитиков, консультантов постановщиков задач, тех.писателей...и с зарплатой ниже обычного code-monkey
==
советую идти в обычные программеры, и не соваться в этот желтый ад.
и хотя и там есть очень интересные задачи, вы осложните себе переход в обычные программеры оттуда

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

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

По литературе для начинающих и не только отвечал здесь. Далее по срокам вкатывания...

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

Если намерен идти наемным питонистом-джуниором, то тут может постигнуть разочарование:

1. На реальном рынке python/django - самая невостребованная web-технология, как в СНГ, так и на западе, в сравнении с php/js/ruby/.net и т.д.
2. Полистай вакансии python-джуниоров - там либо требования к годам опыта, либо требования других языков. В общем, не джуниорские требования в основном.
3. В большинстве вакансий python упоминается либо в качестве доп.языка ("будет плюсом"), либо в качестве бэкграунда для дальнейшего переката на Go, либо в качестве технологии для разного рода аналитиков.
4. На фрилансе также не густо в сравнении с php/js/ruby. Опыт/порфолио по web-python там сложновато наработать (гораздо больший спрос на всякие скрипты автоматизации, парсеры и т.д.).
5. Если ты не из столицы (Москва/Питер/Киев/Минск), то про вакансии python-джуниора вообще забудь, в регионах они если и встречаются, то в качестве исключений, подтверждающих правило. Открыл сейчас HH - по моему миллионнику ни одной.

К чему я это всё...типичный путь в python-разработку лежит через условные "5 лет на php" у подавляющего большинства. Python-проекты также подворачиваются волей случая чаще всего. Естественно, эти люди будут отвечать, что от "hello world" до реальной разработки у них ушло от недели до месяца...но тебя это полезной смысловой нагрузки не принесет, кроме иллюзий.

В среднем, на любой web-технологии от знакомства до уверенного джуниора проходит не менее 1.5 лет ежедневного практического (!) обучения. Т.к. уверенный джуниор - тот, кто не менее полугода трудится в реальном командном проекте и показывает результаты, то с python по вышеобозначенным причинам этот срок может увеличиться.

Разработка под iOS исключительно проста. Наличие отличной документации от Apple. Комьюнити развито достаточно неплохо. Порой Interface Builder существенно сокращает время разработки.
Подводный камень - это наличие MacOS девайса для разработки, но некоторые кодят на вируталках или извращаются еще хлеще.
Возможно для кого-то подводный камень - это платить 99$ в год, чтобы публиковать приложения в AppStore.
Возможно для кого-то подводный камень - это сам процесс публикации приложений в AppStore.
С точки зрения технической Swift язык + XCode IDE перекрывают практически все необходимые потребности для эффективной и быстрой разработки под iOS.

В клиент-серверной истории есть грубо говоря 3 компоненты:
1) Сервер - для вас это сервер VK
2) Клиент - это то что вы хотите написать
3) Протокол - в вашем случае JSON поверх HTTP

В сумме все эти 3 компоненты в VK реализованы в виде архитектурного паттерна REST

В итоге, вам нужно:
1) Изучить реализации RestFull API в VK и Android
2) Изучить json
3) Изучить реализацию HTTP в Android

Ну человек ты конечно замахнулся)

А теперь серьезно, я тоже начинал с этих курсов поэтому опишу свой опыт. Пригодиться тем кто не хочет наступать на грабли. Начинал с них когда интерфейс был на силверлайте и лекций было очень и очень мало, впервые стартовали реальные проекты. Но это было давно и как сейчас там обстоят дела не знаю. Всего прошел 30 уровней.
Итак конкретно за курсы
1) Они помогли научится кодить на джава.(дополнительно к курсам смотрел головоча, по многопоточности и еще паре тем, в книгах читал интересующие главы)
2) Они научили не боятся программирования. Как бы странно это не звучало.
3) Дали основные понятия по алгоритмам и ооп.(основные не значит достаточные:) )
4) В целом самый главный плюс они хорошо структурированы и при возникновении проблем есть сообщество которое поможет. Ведь нет ничего хуже чем то состояние когда пропадает мотивация из-за слишком сложной задачи а спросить не у кого(За мои годы обучения это оказалось самым важным плюсом при выборе любых учебных материалов)

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

Потом я устроился на работу))))))

По времени на ближайшие пол года, просто проходите курсы на javarush. Плюс htmlacademy - на нем курсы по html, css. В этом же заходе изучайте sql по книге издательства o'relly -"Изучаем sql"
Если есть стажировка хорошо, если нету покупаем у Кислина topjava. После javarush это наиболее предпочтительный вариант, первая рассылка за плату остальные бесплатные так что если не уложитесь в сроки можно не беспокоиться у вас всегда будет свежая версия проекта, если паникер забэкапите эти 3 гига данных. На этом этапе главное усвоить то как технологии работают вместе и то как важно выбирать правильную архитектуру. На это уйдет еще пол года.
(Данные сроки актуальны если заниматься кодингом по 6 часов ежедневно, ну в воскресенье можно расслабиться:) )
Английский нужен, учить однозначно. Lingualeo плюс Пимслер плюс учебник плюс сериалы на инглише. На то что бы подтянуть на норм уровень уйдет месяца 4-5.

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

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

junior, mid, senior - это указание уровня опыта. Забугорный аналог наших младший, старший - сотрудник. Такие уровни деления по знаниям приняты почти во всех областях на западе(веб, мобилы, десткоп, наука)

Ну и чисто бытовой совет, старайтесь хорошо кушать, высыпаться и не забивать свою голову программухой. Оставьте себе свободное время это поможет не охладеть. Вот к примеру есть такие кадры которые пишут что они 12 часов 7 дней в неделю батрачат код и через 3 года пропихиваются на джуна в контору "рога копыта" и Там уже растут как профы батрача код по 16 часов в сутки. Это не полезный пример. Голова постоянна забита новыми знаниями, кругом каша и ничего не разложено по полочкам. Вот и выходит что по 12 часов занимаются а толку ноль. Только устают потом и выгорают. Как мне кажеться наиболее удобный распорядок дня это когда часиков в 8-9 вечера ложишься спать, встаешь в 3-4 утра. Выходишь на прогулку дышишь свежим воздухом и топаешь кодить, а лучше учить что-нибудь на свежую голову, это классно и информация лучше усваивается. Кодишь часа 4 потом универ, работа(нужное подчеркнуть). А вечером делаешь какую-нибудь рутину, типа накодить какой-нибудь фигни которая особых умственных способностей не требует. Главное не зарывайтесь. И делайте перерывы между технологиями. К примеру поучили жабу два месяца, а потом следующую недельку вообще ничего не кодите. Это поможет сберечь психологическое здоровье, а утренние прогулки физическое))))

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

Ответ конечно скомканный получился, но если что-то интересует спрашивайте подскажу. Так как сам был недавно студентом.

В Go не предусмотрено столь серьезной поддержки GUI приложений, как, к примеру, в C#.

Перебираете десяток малоудобных библиотек - и на какой то останавливаетесь. Как правило это биндинги для Qt, GTK, WinAPI и пр.
Ни одна из них не будет шибко удобной.

Веб-приложения делаются под браузер, Go тут вообще не при делах. Ну если не считать GopherJS.

Go обеспечивает в бекэнд поддержку для веб-приложения. Само приложение реализуется на JavaScript (и его родичах - TypeScript, Dart и т.п.)

Go развивается как язык для сервисов.
Вот для бэкендов - куча всего.

Ну а писать фронтенд или десктопную морду на Go - не лучший выбор.
Бэкенд для десктопа или веба - да. Но не морду для десктопа, веба.

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

1. Под гео данные сделал отдельное приложение app_geo.
2. В инете нашел, что django.contrib.gis.db.models наследуется от django.db.models, по этому в этом апп-е в models.py прописал

from django.contrib.gis.db import models

В моделях других приложений оставил старый вариант

from django.db import models

3. Поменял в settings.py движок, как указано в шапке.

После миграции в базу добавились парочка новых таблиц из app_geo.
В итоге все работает нормально.

Когда Вам нужно что-то записать, обычно берут листочек и ручку. А можно не ручку, можно карандаш, можно фломастер или перьевую ручку. Полиморфизм будет заключаться в том, что Вам нужен объект, которым можно что-то записать, а какой конкретно и как он реализует саму запись Вас не сильно беспокоит. Т.е. когда Вы скажите: "дай мне объект для записи", Вам можно будет подсунуть любой объект, который как абстракция будет является "перо".

Когда Вы хотите спать, Вы говорите: "дай мне на что можно лечь". И можно будет лечь хоть на диван, хоть на кровать, хоть на кресло-кровать. Абстрактно это все будет "кровать", но реализацию будет иметь разную.

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

Полиморфизм бывает трёх типов: параметрический, ad-hoc и полморфизм подтипов.

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

mapIntFloat :: (Int -> Float) -> [Int] -> [Float]
mapIntFloat f [] = []
mapIntFloat f (x:xs) = (f x) : (map f xs)

mapIntString :: (Int -> String) -> [Int] -> [String]
mapIntString f [] = []
mapIntString f (x:xs) = (f x) : (map f xs)
-- и так далее

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

map :: forall a b. (a -> b) -> [a] -> [b]
map f [] = []
map f (x:xs) = (f x) : (map f xs)

Теперь вместо конкретных типов вроде Int или Float у нас переменные типов: a и b.

Окей, но если копнуть глубже, оказывается, что логика, похожая на map для массивов, применима и к другим типам. Например, к optional-значениям. Без ad-hoc полиморфизма мы напишем что-то типа:

mapList :: forall a b. (a -> b) -> [a] -> [b]
mapList f [] = []
mapList f (x:xs) = (f x) : (mapList f xs)

mapMaybe :: forall a b. (a -> b) -> Maybe a -> Maybe b
mapMaybe f Nothing = Nothing
mapMaybe f (Just x) = Just (f x)

Видно, что логика везде примерно одна и та же, сигнатуры совпадают с точностью до параметризванного типа. Вот для этих случаев и нужен ad-hoc полиморфизм:

class  Functor f  where
    map :: (a -> b) -> f a -> f b

Мы параметризовали нужную нам логику относительно параметризованного типа f и теперь можем писать реализации для конкретных типов:

instance  Functor Maybe  where
    map f Nothing = Nothing
    map f (Just x) = Just (f x)

instance  Functor [] where
    map f [] = []
    map f (x:xs) = (f x) : (map f xs)

Сама функция map теперь имеет тип:

map :: forall f a b. Functor f => (a -> b) -> f a -> f b

Теперь мы можем писать функции, которые работают с любыми функторами, то есть опять-таки сократить повторение логики в коде.

Наконец, полиморфизм подтипов - это несколько другой подход к предыдущей проблеме. Вместо выделения общего интерфейса мы создаём базовый тип и наследуем от него остальные. В этом случае Functor будет абстрактным классом с абстрактным методом map, от которого наследуются типы Maybe, List и т.д. В таком случае сигнатура функции, принимающей и возвращающей функтор, будет выглядеть примерно так: foo :: Functor Int -> Functor String.

Как человек в этом году неожиданно сменивший деятельность с senior php dev на DBA - хочу задать встречный вопрос:
а вы вообще видите вакансии на начинающего-студента-DBA? Целую одну или хотя бы даже две? Для увидевшего SQL вот только что студента и уже желающего быть DBA всего через пару месяцев? Человека, который даже не написал, какую именно СУБД ему интересно изучать до уровня DBA?

Отдельная позиция DBA в проекте - значит ни штатные системные администраторы (со стороны администрирования) ни старшие разработчики (со знанием SQL) уже не обладают достаточными познаниями в используемой СУБД. Но эта БД важна для бизнеса и ищется специалист по ней, который будет обеспечивать хорошую работу этой базы.
Несколько позиций DBA в кампании чтобы брать стажера - это очень большой проект. Эти могут себе позволить отвлекать своих специалистов от работы и вкладывать деньги в выращивание нового специалиста. Если вы чем-то сильно заинтересуете кампанию.

Я не знаю как стать DBA с нуля. Похоже DBA становятся только имея за плечами заметный опыт администрирования или разработки.

Определитесь с конкретной СУБД и прочитайте полностью её мануал. Например мануал postgresql 10 в pdf занимает свыше 3 тысяч страниц A4. На пару месяцев этого уже хватит. А это только мануал. Только по непосредственно СУБД.
Плюс необходимо знать базовое администрирование той ОС под которой эта СУБД используется (например, я как postgresql dba даже близко не представляю что делать с windows - такая экзотика в жизни не встречается. А вот для MS SQL наверняка необязательно разбираться в linux).
Плюс теория: реляционная логика, обеспечение транзакционного, конкурентного доступа, восстановление после сбоев
Плюс практика - активность в профильных сообществах, форумах. Читаете, проверяете, запоминаете, вежливо переспрашиваете в комментариях если вам кажется что предыдущий отвечающий ошибся, отвечаете на вопросы.

Интересно? Вперёд. Но в DBA за 3 месяца из нулевого студента - не верю.