soroka1993

Ответ на вопрос будет сильно зависеть от того, в каком направлении вы думаете развиваться.
Будет ли это сетевое программирование? Тогда это си, в основном.
Может быть, веб-программирование? Тогда тут могут быть php, javascript, python, ruby.
Захотите разрабатывать программы на десктоп? Вам нужны c# или java.
На мобильные платформы? тогда java и objective c (плюс swift).
Или податься в разработку игр? Тогда либо c++, либо с# (для Юнити - наверное, самой популярной платформе).
Хотите экзотики? Приглядитесь к функциональным языкам - Erlang и Haskell.
Разработка железа и драйверов для железа? тогда си (без плюсов) и ассемблер.
Определитесь, что вы хотите, потому что всё объять не получится. Выберите один (или два) направления и добейтесь хорошего уровня в нём. А потом вам будет уже легче двигаться дальше.

Мой совет - попробуйте изучать C# или Java (они во многом похожи) для софта, или Javascript и php/python для веб-приложений и сайтов.

Добавлю, что очень правильный совет дал @tsarevfs - помимо языка программирования, хороший программист должен знать несколько инструментов - и в первую очередь, это система контроля версий, например, git. Плюс юнит-тестирование (хотя это можно начать изучать позже, через годик-два). Плюс - нужно хорошо знать свою IDE, в которой работаете; не вздумайте работать в блокнотиках!

Ещё помимо практики нужно знать теорию - читайте Макконнелла, Фаулера, Мартина, Бека.
Подпишитесь на хабре на пару десятков хабов и регулярно читайте всё подряд. Через годик ваш уровень понимания статей сильно вырастет.

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

UPD. Важное дополнение из обсуждения в комментариях (спасибо @Argentum88 @Deerenaros )
Чтобы стать профессионалом и "востребованным программистом с нормальным заработком", нужно очень хорошо понимать внутреннее устройство тех систем (платформ, фреймворков), на которых идёт работа.
Для этого нужно заглядывать вглубь. Изучив различные мейнстрим-инструменты, посмотреть на аналогичные менее популярные системы. Изучать исходный код используемых open-source библиотек. Написать свою подобную систему. Для web - написать свою CMS (хотя бы базовую). Для десктоп-программ - попробовать программировать без навороченных библиотек, которые делают рутинную работу за программиста. Для разработчика игр - сделать простую игру на базовом инструментарии платформы, где всё придётся делать своими руками.
Всё это даст возможность проникнуться, почему всё делается именно так, даст понимание взаимосвязей разных частей программы.
А потом, осознав это, выбрать один из уже готовых инструментов, и продолжать писать на нём, уже обладая более глубоким его пониманием.

В общем, с дипломами вот какая штука.

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

Yet another framework - это не улучшение (вряд ли Вы напишете что-то лучше существующих решений).

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

Иными словами - сначала наука, потом техническая реализация (которая ВАКу будет неинтересна).

Конкретную тему пока не могу предложить, уточните кафедру, лабораторию и чем занимаетесь вообще.

Отвечу сам себе.
Здесь есть полезная конкретная информация о технической реализации.

А если вкратце, то...

Для авторизации, регистрации используется все та же таблица 'users'. Вместе с обычной регистрацией и авторизацией, когда при регистрации (в самом простом виде) в таблицу 'users' добавляются email, password и login пользователя, а при авторизации проверяется соответствие введенных login'а и password'а существующим в базе данных, аналогичным образом используется и регистрация/авторизация через социальные сети. Только в данном случае источником данных о пользователе для его регистрации является не непосредственный пользователь, который вводит данные в форму, а соц. сеть. Регистрация в данном случае достаточно прозрачная, т.е. не видна пользователю. Схема примерно следующая (без особенностей работы Oauth-протокола):

1) Пользователь выбирает вход через соц. сеть.
2) Происходит обращение к странице авторизации в этой соц. сети, если человек еще не авторизовывался там. После ввода данных, а если он ранее авторизовывался, происходит запрос на разрешение использования его данных.
3) Если человек отказывается, то на этом конец. Если дает согласие, то выполняется перенаправление на указанную в настройках Oauth страницу сайта.
4) У каждого пользователя в соц. сетях есть свой уникальный идентификатор, который можно запрашивать. Для своей таблицы 'users' нужно добавить пару дополнительных полей (например, вот такие): auth_via (enum('native, 'vk', 'mailru', '...')) - для обозначения типа регистрации пользователя, и social_id - здесь будет храниться уникальный идентификатор в соц. сети. Если нужно хранить какие-то специфические данные этого пользователя из соц. сетей, то можно создать доп. поля для этих данных.
5) После того, как пользователь дал разрешение на использование его данных, необходимо запросить нужные данные от соц. сети, в т.ч. и идентификатор пользователя в соц. сети. Вот здесь и начинается невидимый процесс регистрации. Нужно проверить есть ли в БД пользователь с таким social_id, если нет, то вставляем social_id, данные пользователя из соц. сети, по необходимости, в БД. Все, пользователь зарегистрирован.
Если же данные о пользователе есть, то необходимо запросить актуальные данные из соц. сети, сравнить их с теми, что в базе и если они изменились, то обновить их и в своей базе данных, если нет, то просто переходим к следующему шагу.
6) Создается сессия с данными пользователя.

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



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

'AND WHERE `auth_via`="native"'

, чтобы исключить пользователей, зарегистрированных из соц. сетей.

Как видно, для каждого пользователя в таблице создается внутренний (внутрисайтовый, если так можно выразиться) первичный, автоинкрементный ключ. Соответственно, нет разницы для логики сайта между пользователем, зарегистрированным через соц. сеть и через сайт. Если говорить об интернет-магазине, то, для привязки заказов к пользователю, можно использовать единый, внутренний идентификатор ID.