pletinsky

Я не php девелопер. Насколько я понимаю это кусок php кода, представляющий из себя обьект, вместо его представления в json.

То есть Вам нужно завршить работу этих чуваков, которые не дописали нужный код по сериализации обьекта в json.

1) Вытащите содержимое тега pre в строку.
2) Поместите его внутрь следующей сроки: «json_encode({Ваш массив})» и добавьте еще вывод результата энкодинга в файл.
3) Выполните данный код php интерпретатором.
4) Прочитайте получившейся json.

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

Смотря какими сущностями Вы оперируете. Если есть сущность пользователь, то можно ли говорить о том, что он имеет разные режимы View — как авторизация и регистрация? Думаю в вашем случае врятли.

Регистрация это сущность, которая регистрирует (или создает) нового пользователя системы.
Авторизация — сущность, которая находит нужного пользователя системы по указанным идентификаторам и авторизует его.

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

В конце концов для авторизации далеко не всегда нужен юзернейм и пароль (авторизация через сторонние сервисы например).

Выхода 3 на мой взгляд.

1) Маскимально детализировать требования, разрабатывая ТЗ до начала разработки проводя масшабную работу с заказчиком.
Тогда риски пролета будут зависеь прежде всего от того, как вы проведете работу по тому, чтобы заказчик подписался на составленные вами требования и от того, насколько детально и точно вы их опишите.
Достоинства: хорошо работает для небольших проектов, для конкурсных проектов, работа по ТЗ может в идеале стать чисто технологической и идти как по маслу.
Недостатки: огромная работа по формированию требований, высокие риски того, что по дороге выясниться, что все надо было делать не так, необходимость продавать заказчику данный цикл работы.

2) Провести высокоуровневую планнинг сессию оценивая не только обьем работ, но и предполагаемые риски опираясь на опыт предыдущих оценок проектов.
Тогда риски пролета будут зависеть от того, насколько совершенные технологии для оценок вы используете.
Достоинства: хорошо работает если есть большой опыт ведения проектов и с них снимались метрики.
Недостатки: требует определенного уровня профессионализма в менеджменте проектов.

3) Работать итеративно выпуская короткие релизы с кусочками функциональности с оплатой за каждый релиз.
(Итеративность — это не обязательно эджайл).
Риски пролета будут зависить прежде всего от того, сумеете ли вы сформировать требования так, чтобы выпускать приложение такими релизами. Это как правило возможно, но получается не у всех.
Достоинства: риски провалится с пониманием требований сведены к минимуму, так как мы их формируем по мере работы, заказчик доволен видя постоянный прогресс, можно на основании предыдущих итераций корректировать дальнейшие прогнозы оставшевося времени.
Недостатки: требует серьезной обработки заказчика для работы в таком ключе, особенно для тех, у кого уже выделен бюджет на реализацию и на конкурсе.

Чесно говоря сомневаюсь, что такая сертификация сейчас возможна.

1) Дело в том. то, как люди пишут код очень сильно зависит от инструментария и условий написания.

Дай разработчику .net например, привыкшему работать с resharper — visual studio без решарпера — и он замонается выискивать внешние библиотеки для подключения — и возможно напишет чтонибудь не то. Про практику написания кода на бумажке на интервью в некоторые компании я уж вообще молчу. Даже просто смотреть на распечатанный в черно белых тонах код на бумажке некомфортно.
Смена девелоперской среды может все очень сильно все испортить — так как ко всем нужно привыкать какое то время.

2) Плохой — хороший код гораздо более субьективное понятие, чем принято считать.

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

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

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

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

Если вы разработчик — то вероятно знаете про существование веб систем для ведения проекта. Такие системы обычно включают в себя и ведение документации. Там обычно используется и вики и теги и разные другие механизмы.

Соответственно мы отделяем задачу сохранения статей в интернете и документов от классификации.
Сохранять можно например в Evernote или OneNote, указывая какой нибудь специфический тег. А дальше полученные ссылки можете добавлять в систему ведения проекта.

Технология под дот нет называется asp.net, а не asp. Asp -технология тоже существует и она другая.

На мой взгляд если будете использовать современный подходы к разработке под .net (asp.net mvc 3.0-4.0), то стоимость разработки сайта будет существенно ниже, чем при использовании java.
Это результат и очень развитых инструментальных средств и очень развитого языка программирования.
Все эти средства вы можете получить бесплатно по системе поддержки стартапов или студентов.

Вам не понадобится ничего кроме MS Visual Studio на вашем этапе. Когда сайт будет создан — захостите бесплатно (первый год) например на амазоне. Есть и другие варианты.

Да, задача специфическа, скорее всего такого приложения не существует в готовом виде.

Вообще вот тут все написано :)

Есть мощные и тяжелые продукты вроде Selenium.
Есть маленькие и простые, но решающие ваши задачи, вроде такого. Тут даже написано как скриншоты делать.

Но программировать все равно придется, но не много. Задача простая очень.