index0h

Пользователь и пароль на базу данных к которой нужно получить доступ

Читайте документацию к приложению, с которым шла бд
У меня, например, логин "root", а пароль пустой

нормальный инструмент+коннекторы с вставками+опыт.

Присоединяюсь ко всем предыдущим ораторам, но от себя добавлю:
Ваш шифр ещё менее надёжен чем стандартный XOR, так как функция md5 возвращает строку. В этой строке в каждой позиции может стоять один из 16 символов (а по хорошему символ маски должен покрывать весть байт целиком).
Что Вас сподвигло на разработку собственного шифра без знания криптографии?
Если вам просто нужно прятать какие то осмысленные текстовые последовательности в файле или другом наборе данных. чтобы они не были видны при беглом просмотре, то возможно Ваш шифр и подойдёт, но не более того.

Насколько устойчив этот метод шифровании?

При шифровании одним ключом нескольких сообщений - очень ненадежен. Да и без этого, у вас длина ключа в общем случае меньше длины сообщения. Попробуйте зашифровать длинную строку (~200-300 байт) и проверьте результат.

Сколько минут потребуется профессиональному криптографу для расшифровки?

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

А есть ли абсолютный метод шифрований?

Что значит "абсолютный"? Абсолютно стойкий? Абсолютно удобный?

Никогда, ну то есть совсем никогда не используйте придуманные вами методы шифрования.

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

В любом случае, вы изобрели плохенькую симметричную криптосистему, В пхп есть встроенная и хорошая: mcrypt, используйте ее.

1. Принципиальных качественных преимуществ у node.js перед остальными языками нет, как впрочем и недостатков. Просто yet another язык со своими особенностями. Соответственно если в вопросе заменить node.js на php/ruby/python итд - ничего не изменится.
Вопрос по сути абстрактный "почему все не перешли на язык %%%%%"

2. Ответ на абстрактный вопрос:
а) Потому что существует огромное количество legacy кода который нужно поддерживать. Работы по поддержке и развитию существующего кода на порядок больше чем написания с нуля нового
б) Потому что у разработчиков есть свой стек любимых технологий, изменять который без явных экономических причин основная масса не готова
в) Потому что умные технические менеджеры выбирают стек технологий проекта исходя из имеющихся под рукой разработчиков и легкости поиска и заменимости оных.

UPD
hbrmdc

У NodeJS есть уникальные и очень весомые преимущества, которых нет ни у одного другого языка. Например то, что это JS, и, следовательно, нет необходимости разучивать лишние языки - можно весь webapp писать на js.
Личные предпочтения обоснованные привычками - это не имеющий значения аргумент в данном вопросе.

1) Есть отличия, да. Только не те о которых Вы пишите. То что это "JS" вообще ни на что не влияет.
JS хорошо знают фронтендщики - а кто пустит фронтэндщика к внутренней архитектуре? Там подход совершенно другой нужен, другие навыки, другое понимание как это все работает. Просто пересадить человека с фронта на бек - нельзя.

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

2) Личные предпочтения обоснованные привычками это основной аргумент.
Я вот умею в php, умею в ноду, умею в еще десяток умных слов.
Мне нужна новая команда на новый проект.
Я открываю hh и что я вижу: node.js 279 резюме из которых половина фронтэндщики.
PHP - 9613 резюме. Даже если 90% разработчиков PHP на hh - уроды которых к коду нельзя подпускать на пушечный выстрел - останется все равно в 3 раза больше чем есть node.js.
Собственно на этом выбор и закончен.

На малопопулярных языках пишут в случаях:
a) это мелкий сервис с неявными перспективами который можно переписать за неделю
б) это проект "для души" разработчика.

Получается замкнутый круг на самом деле.
Менеджер смотрит резюме, резюме на node.js нет =>
Менеджер не начнет проект на node.js =>
Не возникнет вакансия на node.js =>
Разработчик анализируя вакансии не увидит вакансий на node.js =>
Разработчик будет учить что то другое =>
Менеджер смотрит резюме, резюме на node.js нет...

Переломить ситуацию могут только очень крупные игроки обладающие возможностями формирования рынка (например Apple и Swift), и то не со 100% гарантией (samsung&c и Tizen)

docuwiki посмотрите.
Вообще mediawiki и docuwiki одни из самых удобных.

А с чего вы взяли что разработчики редмайна дадут вам права создавать проекты в своем редмайне.
Скачайте и установите редмайн у себя и уже создавайте проекты сколько влезет.
Не так вы делаете скорее всего мозг

Да потому что поисковых запросов таких много. К примеру go V.S php В основном кучи пхп кодеров увидели что go язык для веба и работает быстрее всех и пошли гуглить тесты (сам таким вчера был :D )
а блогеры рады стараться ;)

Скорее всего сравнивают те, кто имел/имеет отношение к Руби, но уперся в его проблемы с производительностью, многопоточностью, етц... и пробует новые платформы. Т.е. такой народ сравнивать более-менее толково может только с руби. Ну и эти граждане не забывают держать руби-сообщество в курсе своих экспериментов -- понятно что Ц-программист не будет сравнивать Ц с Го в руби-блоге

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

Можно настраивать CI, можно разводить agile процессы, но главное - выяснить требования заказчика, и подстраиваться под них.

Ну это же очевидно: Swift - для разработки под продукцию эпла, Go - для всего остального. Если вы хотите писать приложения под айфон, тогда берите Swift. А если хотите писать сетевые сервисы под Linux, тогда учите Go.

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

Да. А вам сколько надо?

че? =)
1 таблица на это дело + база городов. Фреймворк не нужен.

Вы хотите все и с сразу - так не бывает, люди годами учатся и набирают опыт.
Официальная документация по php написана step by step, начните с него, так и до ООП дойдете, а далее уже углубляетесь в MVC, Patterns ....