azverin

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

Это мой собственный опыт.

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

Все это дало мне то, что неявным образом у меня сформировалось мышление, привычки, действия, ритуалы и др. таким образом, что аж диву даешься "И это я?". К примеру от математиков прям железобетонно вбилось в голову фраза "Необходимо и достаточно", т.е. есть задача значит надо сделать настолько мало насколько это возможно, но при этом чтобы задача была решена!

Рекомендую Вам прежде всего надо спросить себя "А что именно хочу?" и "Какие у меня мечты?". Ежедневно спрашивать себя "Какие задачи должен сегодня сделать чтобы хоть на чуть чуть приблизиться к моим мечтам?".

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

1. 90% заказов что я вижу - это постоянное допиливание чего-либо. За копейки. Фактически - говнокодинг какой-то. И при этом туча конкурентов, которые готовые работать за гроши. Мне вообще не хочется напрягаться из-за копеек и каждый раз вникать в новую задачу, ибо та жалкая тысяча рублей что я заработаю на фрилансе (если обойду орду школьников) мне и так придет в 6 утра с сапы))
Мне гораздо комфортнее работать в офисе с одним проектом, зачастую написав в день пару строк кода и получать стабильно з/п.

2. Я бы с радостью бы занялся серьезным проектом, разработкой (а не допиливанием опенсорса), но я не встречал подобных вакансий ни разу. Очень сомневаюсь, что сейчас кто-то станет инвестировать в разработку ИМ с нуля, скажем.

3. Процитирую Лурк:

...подавляющее число действительно серьезных коммерческих проектов, как правило связанных с производством ништяков, реализуются коллективом, а не психами-одиночками, и никакая координация через e-mail, web-камеры и мессенджеры не спасет проект от бесславной гибели, если сотрудники не будут IRL бегать от стола к столу, тыкать друг-друга в мониторы и посещать всяческие стафф-митинги.

- я имею опыт работы в больших корпорациях и могу подписаться под каждым словом этой цитаты. Масштабные проекты, со сложной бизнес-логикой, с огромным количеством кода не могут держаться на удаленке. Нужна постоянная координациях всех дирекций и IT-отделов. Как воздух необходимы митинги разработчиков. Очень долго и часто длятся обсуждения различных решений по поставленным свыше задачам. В переговорках сидят тимлиды и разработчики, ребята из маркетинга, из иных подразделений. Удаленно бы это все просто не работало. Никогда. И с ужасом вспоминаю, как мы однажды "трахались" по скайпу с удаленным верстальщиком - скорость работы занижалась в разы. Он слал какие-то куски JS-кода и мы его тыкали в проект. Мы опплевались.

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

Очень подозреваю, что фриланс в 90% случае - это типичный говнокодинг на опенсорсах и пр. низкоквалифицированные вещи, ибо мне очень трудно представить действительно серьезную компанию, которая будет инвестировать в проект, который пишут удаленно какие-то хрены с горы без каких-либо гарантий и отчетности. И мне в разы сложнее представить опытного разработчика, который не может переехать в другой город и получать там солидные деньги, если он действительно профи. А опенсорс допиливать и джумлы ставить, выдавая это за результат своей деятельности... для меня это не работа. Совесть бы замучала.

4. Финансовая свобода, о которой говорят фрилансеры, меня как-то "пугает". Я в 12 году писал статью про то, что можно считать действительно финансовой свободой разработчику, почитайте - www.phpinfo.su/articles/additionally/azy_svobodnog...
Суть очень простая - фриланс - этот тот же каторжный труд. Это инвестирование своего времени в точно такую же работу, как и в офисе. Финансовая свобода - это пассивный доход. Это свой бизнес, когда результат НЕ ЗАВИСИТ от вашей ежедневной деятельности. С точки зрения здравого смысла, владелец павильона с жрачкой/одеждой/водкой имеет куда больше свобод, нежели IT-шный фрилансер.

В принципе учебник для этого не нужен, нормализация - минимизация избыточности данных, имеет 5 форм. Первые три формы нацелены на связанность данных, две последних на улучшение структуры. Очень хорошо описано здесь - citforum.ru/database/dblearn/index.shtml (главы 6 и 7)
Кратко здесь - support.microsoft.com/kb/283878/ru

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

А вот и видео неплохое - www.youtube.com/watch?v=1GWx5CZdSCg

Я увидел в Вашем вопросе две части.

Как правильно организовать деплой (выкладку работоспособного кода на сервер)?

В самом простом случае Вам подойдет связка ssh + git pull на сервере. В этом случае на сервер будут доставлены патчи коммитов, которые есть в репозитории, но еще не появились на сервере, т.е. «только обновления файлов, которые сейчас существуют». Этот метод довольно подробно обсудили в ответах на другой вопрос.

Если хочется автоматизировать процесс, что похвально, то я вижу три доступных инструмента для этого: Capistrano, Mina (мой персональный фаворит) и Vlad the Deployer. Все три проекта схожи по сути. Принцип их работы таков:

1. Подключиться к целевому серверу.
2. Залить обновление кода из репозитория.
3. Выполнить предписанные Вами инструкции (перезапуск демонов, сброс индексов, обновление структуры БД и прочее).
4. ...
5. PROFIT!

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

Как организовать процесс тестирования?

Если Вы еще не определились с методикой тестирования (Test Driven Development, Behavior Driven Development, Лень-Driven Development), то Вам следует для начала заняться именно этим.

Скорее всего, тесты будут выполняться на Вашей локальной машине, пока Вы пишете код. Используя RSpec, я держу открытым Guard. Guard отслеживает изменения в коде и запускает набор юнит-тестов, которые покрывают измененный код. Весь процесс занимает не больше минуты-двух, и особо не напрягает. Как только я вижу провалившийся тест, я меняю код до тех пор, пока он не станет зеленым. Пока тестов мало (это не самый лучший знак, к слову), Вы работаете один, локального запуска перед деплоем может оказаться достаточно — например, чтобы проверить релиз на доступность критического функционала: регистрации, покупки, создание постов и т.п.

В какой-то момент речь может зайти о Continious Integration. Это возможность иметь стабильный билд в любой отрезок времени, а так же принимать решение о годности каждого отдельного коммита. Сопряжено с деплоем кода на integration-сервер и запуском на нем тестов. Скорее всего, это Вас не интересует, если Вы не работаете в команде. Но, для полноты картины, Вы можете понаблюдать за билдами на Travis CI известных Open Source проектов: Symfony 2 и Ruby on Rails.

Таким образом

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

Приведите в порядок Ваш репозиторий с кодом, используйте mina для деплоя и запускайте тесты на Вашей локальной рабочей машине. Как только Вы почувствуете, что этого не достаточно — Вы наверняка уже будете знать, куда шагать дальше.

Основное преимущество объектов, полизморфизм, на:
function func($obj) {
$obj->method1();
$obj->medhod2();
}
Получили какой-то объект и работаем с ним через определённый интерфейс не задумываясь о его реализации. Если вызывающему коду нужно будет подсунуть нам другую реализацию, нас это не волнует.

И откуда получен этот объект, через Singleton или нет, много подобных объектов в системе или он один, нам не интересно.
А со вторым способом мы жестко привязались к классу.