German Jet

Разработка под 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 месяца из нулевого студента - не верю.

Для понимания указателей нужно знать язык программирования низкого уровня: ассемблер. Именно ассемблер может более точно объяснить принцип работы указателей. Так как указатели пришли из мира низкоуровневого программирования. Но написали вы странно: когда пишете про C#, то пишете, что знакомы с ООП, а когда пишете про C++ - уже незнакомы с ООП. ООП - это всего лишь подход к программированию. И этот подход для каждого языка программирования общий. Если хотите писать игры на C#, то для этого есть Unity. Да и для большинства прикладных задач будет достаточно C#. С++ - хорош для реализации производительных задач. Порой на практике используют смешанный подход: что требуется для высокой производительности - пишут на С++, а всё остальное - уже на C#. Вполне нормальная практика. В программировании важно уметь работать с алгоритмами, продумывать весь механизм работы, понимать, как всё работает. С плохим алгоритмом на любом языке программирования программа работать будет плохо.

Ответ "никак" можно всегда найти на просторах гугла. Для аналогии можно привести пример обучению веб разработки, когда есть только телефон. Ну так себе, и не удобно и очень сложно.
Но какие действительно есть варианты? Сейчас много коворкингов с маками, можно их арендовать и обучаться разработке для iOS. Проходить курсы с их железом (такие сложно найти), после которых вас, скорее всего заберет какая-то компания на стажировку. Там можно поселиться на время обучения (шутка Шредингера). Многие компании ищут iOS разработчиков и готовы инвестировать в Вас при определенных условиях. Так дайте им то, чего они хотят, а вы получите знания и опыт.

Установка MS SQL ODBC Driver под Linux и сборка плагина для Qt 5.9: tutorial.

Дружище, ну ты темы плодишь))

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

И не нужно сравнивать Data scince с разработкой ПО. Анализ больших данных и разработка хоть и относится к IT сфере, но пересекаются косвенно.

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

Он на взлете (опять) зарубежом, используется как правило аналитиками (data scientist). Взлет связан в основном с хайпом вокруг анализа данных, машинного обучения и бигдаты. R очень хорош для быстрого прототипирования на небольшом наборе данных или уже для "окончательного" анализа и визуализации, опять же на небольшом или среднем наборе данных, которые прошли предварительную обработку и очистку. Много библиотек связанных с матстатистикой, машинным обучением, анализом данных, визуализацией. Оракл обещал вставить возможность писать хранимки на R в свою базу данных, но я не следил сделали ли.
Я проходил в свое время курсы на Coursera по анализу данных, мне R как сам язык понравился средне. Сейчас идет конкуренция между R и питоном с библиотеками типа numpy, pandas, sklearn и тд за звание лучшего инструмента для анализа данных. Плюс есть вендорские инструменты, типа SPSS, которые предлагают ту же возможность.
Что касаемо вакансий в вашем регионе, то они есть, но их мало. Вот пример https://hh.ru/vacancy/20496633?query=%D0%B0%D0%BD%...
Я бы не стал расчитывать что в России вообще, а тем более за пределами Москвы вы сможете легко найти работу аналитиком данных, не имея реального опыта и успехов в этой области. Но, повторюсь, за рубежом профессия Аналитка Данных сейчас очень популярна и язык R часто считается одним из необходимых инструментов, которым он должен владеть (см. ремарку про питон).