Shodan Mind

@rgamretsky я начинал год назад с английским явно ниже intermediate(да и сейчас вряд ли он выше этого левела). Тоже с Google Translate сперва все письма писал. В процессе приноровился, чуть позанимался с LinguaLeo, уже давно могу без словаря писать. Язык сам прокачивается в процессе переписки.

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

Безусловно, язык нужно совершенствовать, это поможет вам лучше продавать себя и изъясняться. Но, поверьте, стихи и огромные тексты писать вам вряд ли придется, так что порога никакого нет. Главное, не отчаивайтесь в ситуациях, когда ваш язык кого-то смутил. Таких обычно 5-10%. Остальные, особенно, американцы, вполне терпимо относятся к косякам в языке. Так как сами пишут совсем уж не академично.

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

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

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

Относительно IT образования в России все не столь круто) И будет оставаться столь же не круто доколе Бизнес сам не станет обучать кадры. С первого курса. Не учителя которые отошли от дел пару десятков лет назад, а реальные специалисты которые крутятся в перспективных направлениях, которые будут вести лекции в Вузе. Так происходит в крутых ВЗ западных стран. Считаю это единственно верным способом обучения в ВУЗах компетентных специалистов.
Некоторые ведущие ВУЗы кстати уже пытаются прийти к этой модели, создавая новые IT специальности и сразу заключающие соглашения с крупными или ведущими IT компаниями чтобы они с первого курса выделяли специалистов для обучения. Надеюсь пока эти отчасти экспериментальные специальности не только приживутся, но и вскоре перенесут данную модель обучения на все остальные специальности крупнейших ВУЗов страны)

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

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

Для авторизации, регистрации используется все та же таблица '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.

Вообще, языки гендерных различий не имеют. Но если под "девушкой" понимается легкомысленная особь, которой будет лень вникать в детали и она не собирается на этом строить карьеру, то язык должен быть предельно простым и логичным. Python, например, или Java/C#.
Если же понимать это как кокетство, то лучше по проторенной дорожке: C -> C++ -> C#/Java, если по пути не затянет еще куда-нибудь, вроде веба =)