Дмитрий Энтелис

как я смс-то буду отправлять...

sms.ru - смска от 25 копеек. Вполне "бесплатно".

Будет ли считаться если я сделаю: пароль + код на email?

Будет. Но смс imho правильней.

Профильное ВО в IT полезно в 2х случаях:
1) Вы занимаетесь enterprise разработкой: крупные интеграторы, банки, нефтянка, итд. Они любят всяко-разные сертификаты.
2) Вы задались целью эммигрировать (usa, европа, etc)

Во всех остальных случаях всем глубоко плевать какое у Вас образование и есть ли оно вообще.
Важны навыки и портфолио как их заочное подтверждение.

Кирилл Кривицкий: Дополню: что бы что то реализовать нужно сначала придумать как именно это реализовать. Составить список конкретных задач, детализировать используемые алгоритмы и структуры данных, итд. Это работа которую в любом случае придется сделать, просто можно поручить её профессионалам - тимлидеру, pm, итд - и получить на выходе продукт быстрее, качественнее, но дороже - а можно отдать на откуп самому разработчику. Но в любом случае это значительный объем необходимой работы, который никто не будет делать бесплатно

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

Собственно для этого и придумали PSR4 (хотя нечто похожее можно и без namespace использовать легко)
Главная идея - по названию класса должно быть однозначно понятно где он лежит.
Если вдруг есть любимый класс у которого название не совпадает с местоположением - вот тогда на сцену выходит map файл который заранее заполняется ручками разработчика.

Крупные ежегодные (некоторые еще не анонсированы на следующий раз):
www.highload.ru
ritfest.ru
whalerider.ru
https://devconf.ru/ru
2015.russianinternetforum.ru
www.spmconf.ru/ru/index
msk16.agiledays.ru
www.msdevcon.ru

Списки:
runet-id.com/events/2015/9 - не все, в основном мелкие но бывает интересные
https://events.yandex.ru/ - проводит яндекс, но иногда бывает интересно и остальным
rusbase.com/calendar

PS disclaimer: именно по дизайну я затрудняюсь назвать конференции, несколько далек от этой области. Но потоки по UX бывают регулярно.

Поймите, все утечки которые происходят - в 99% это не exploit, а тупо человеческий фактор.
Все решения с конфигами сервера, ORM и прочим - абсолютно бессмысленны когда вашему сисадмину подарят новый X6 и он сольет дамп сервера целиком.

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

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

Решение 1:
Пишем хранимку которая отдает связанные логины-пароли от внешнего сервиса по логину-паролю от нашего мульти-мессенджера.
Доступ к изменению хранимки и к базе в которой лежат все пароли есть у 1 человека в компании. Остальные тупо ходят через хранимку. Способа получить полный список логинов-паролей сервиса не существует.

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

Решение 2:
Разделяем каждый пароль от внешнего сервиса на N частей (N >= 3)
Дублируем решение 1 на N серверов, каждый пароль получается размазан на N серверов.
Первоначальная хранимка занимается тем что собирает данные из N хранимок с N серверов.
У каждого сервера - свой ответственный человек. Доступ к каждому серверу есть только у ответственного и у bigboss (на случай внештатных ситуаций).

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

Правильный ответ - в зависимости от сферы в которой хотите работать.

Субъективно:
Хотите в enterprise - учите java.
Хотите мобильные приложение - objective c & swift под ios / java android sdk для android
Хотите фрилансить по сайтам - PHP
Хотите сидеть в студии и писать сайты - php, ruby, python
Хотите много общаться с бухгалтерией - 1C
Хотите заниматься frontend - javascript вообще + angular.js в частности.
...

В 99% случаев надо экономить ресурс под названием "время программиста".
А в оставшемся 1% - исходить из реальной задачи и реальных условий по объему данных, имеющимся аппаратным ресурсам и требуемому быстродействию.