vildulv

1. Обговариваешь ТЗ. Получаешь логины, явка, пароли.
2. Обговариваешь срок, порядок и канал оплаты. Это тоже важно.
3. Поднимаешь копию проекта у себя на хостинге/сервере и т.д. Не рекомендую пользоваться всяческими денверами. Например поведение php под liniux может отличаться от его поведения под windows.
4. Кодишь, кодишь, кодишь.
5. Показываешь заказчику на своем сервере.
6. Получаешь оплату.
7. Переносишь изменения к заказчику. Тут пригодится вышеупомянутый GIT.
Рекомендации:
На рабочем месте лучше держать linux. Во-первых как выше написал родная среда для web-приложений, во-вторых проще будет админить на vps и хостингах. А админить или хотя бы диагностировать проблему приходится часто. Особенно на мелких проектах.
Использовать VCS, например GIT.
Держать несколько каналов для оплаты. Например банковская карта, Яндекс.деньги, Qiwi и Webmoney.
Сразу проработать схемы перевода прибыли в доступные для траты денежные средства.
Не лениться и не бояться.
Все начинали с мелких проектов, всех хоть раз кидали.
Во фрилансе учатся на ошибках. Редко получается учиться по готовым руководствам и боже упаси всяким тренингам и видеокурсам.

1. Юзаю notepad++ и Far (всё настроено в плане подсветки и подсказок)
2. Формирование краткого перечня работ и стоимости, предоплата от клиента 50%, составление ТЗ (если необходимо), затем уже сама работа по кодингу. (порядок следования очерёдности задач - сохранён)
3. Делается полный бэкап текущего сайта средствами хостинга.
4. Если есть возможность разделить логику разработки от действующего функционала (чтобы текущая работа не оказывала влияние на реальных посетителей) - правлю обычно сразу на (S)FTP. Иначе - только на своём хостинге.
5. Бэкапы - делаю копированием файла/папки с добавлением .ORIG в полное имя файла (например, файл: index.php.ORIG или реже, директория: TEMPLATE.ORIG).
6. В текстовик (для себя) - пишу всё, что я сделал, чтобы по нему можно было легко восстановить последовательность действий.
7. Сдаю работу, получаю деньги, делаю полный бэкап сайта после всей работы и отдаю клиенту.

Теперь, главное:
1. Никогда не тяните время
2. Клиент платит не за часы, а за конечную сделанную Вами работу (если это не так - значит не нужно работать с таким клиентом)
3. Если клиент требует больше работы, чем вы с ним договорились до предоплаты - найдите компромисс, чтобы вариант устроил всех, закройте проект и больше не работайте с этим клиентом.

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

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

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

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

• www.nczonline.net
  
• 2ality.com
  
• ponyfoo.com
  
• mathiasbynens.be
  
• davidwalsh.name
  
• rmurphey.com/archives
  
• caolan.org
  
• perfectionkills.com
  
• www.bennadel.com
  
• addyosmani.com/blog/
  
• dmitrysoshnikov.com
  
• yehudakatz.com
  
• ncombo.wordpress.com
  

Внутри Docker только Linux, и, экспериментально, FreeBSD. Запускается нативно под Linux и, экспериментально, под FreeBSD. Под MacOSX, Windows - через виртуальную машину.

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

Это почти виртуальная машина. Почти, да не совсем.

Есть такое понятие "ад зависимостей". Любое ПО устанавливаемое на компьютер, тянет за собой зависимости (конфигурационные файлы, статические файлы называемые обычно asset, вспомогательные утилиты/сервисы, библиотеки и пр.). Ряд из этих библиотек/утилит/сервисов несовместим друг с другом. А с учетом того, что каждая из этих библиотек/утилит/сервисов имеет и свои зависимости - ситуация еще хуже.

Например, мы используем Yandex.Cocaine, которая нормально компилируется только на Ubuntu 14.04 (и, вроде, на Debian 7). Но не под CentOS 6, 7, Debian 8, FreeBSD 9, 10, Ubuntu 15, 16 и пр. - скомпилировать его невозможно. Запускаем в этих операционных системах в Докере.

С другой стороны, и одновременно с этим, вам необходимо установить другое, более современное ПО. И одновременно более старое. Причем речь даже не идет об серьезно отличающихся версиях Linux. Например, одно ПО требует не менее Ubuntu 14.10, а другое не более Linux 14.04.

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

Таким образом, мы имеем бинарный файл запускаемый как бы в своей операционной системе.

Вы можете сказать - ба, да это же давно известная виртуальная машина. Но нет, это не так. Это так называемые контейнера. Никакой виртуальной машиной там и не пахнет. За исключением Windows и MacOSX, где работа без виртуальном машины пока экспериментально возможно только, а нормой в этих ОС является использование Докера внутри полноценной виртуальной машины.

Но виртуальные машины с Докером используются только для разработки. Для запуска в production виртуальные машины с Докер не используются.

Докер использует контейнеры операционной системы. LXC в Linux, Jails в FreeBSD. Контейнер - это область операционной системы, изолированная от основной части операционной системы. В контейнере свое дерево каталогов (включая системные /dev, /bin, /sbin и пр.), свои сетевые порты и пр. и пр.

Но при этом не используется полная виртуализация. Что существенно экономит ресурсы. Запустить 100 полноценных виртуальных машин вряд ли получится даже на мощном сервере. А вот запустить 100 контейнеров Docker даже на слабом домашнем компьютере - возможно.

Правда использование не полной виртуализации ограничивает использование операционных систем внутри контейнеров. Как правило, это специально подготовленные версии Linux или FreeBSD. Именно специально подготовленные. Windows - в принципе в контейнере запустить невозможно.

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

Зачем это используется?

Ребята из всяческих Dropbox, Facebook и и пр. гигантах, запускающие по 1 млн. различных программ в своих сервисах, столкнулись, что невозможно везде гарантировать идентичные настройки операционной системы. А это критично.

Вплоть до того, что идеально написанная и оттестированная программа на реальном сервере начинает себя вести непредсказуемо.

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

Более того - изначально разработчик программного обеспечения тестирует программу в контейнере Докер, с определенными настроками. И в этом же (или с такими же настройками) контейнере Докера программа уезжает на сервер.

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

До этого люди мучались, придумывали хитрые инсталяторы...

Потом плюнули на попытки упорядочить окружение в ОС - и сейчас концепция такова - устанавливать программы на сервера вместе со своими индивидуально настроенными под них операционными системами - то есть внутри контейнеров. 1 контейнер = 1 настройка ОС = 1 программа внутри.

Другими словами:

• Докер-контейнер нужно использовать для отладки.
  
• Тот же Докер-контейнер нужно использовать и на сервере.
  

Это позволяет не трудиться с настройками "под сервер" локально на машине разработчика. Это позволяет разрабатывать на машине разработчика совершенно разные программы одновременно, которые требует несовместимых настроек операционной системы. Это позволяет давать гораздо больше гарантий, что программа на сервере будет вести себя также как и на машине разработчика. Это позволяет разрабатывать под Windows/MacOSX с удобным "прозрачным" тестированием под Linux.

Докер применим к созданию/настройке только серверного программного обеспечения под Linux (экспериментально под FreeBSD). Не для смартфонов. А если десктопов - то только программное обеспечение без GUI.

Посколько Докер позволил одним махом упростить работу разработчикам и админам и повысить качество результата - сейчас бум на Докер. Придумано огромная гора инструментов для управления развертыванием приложений созданных с Докером. Если раньше чтобы запустить 10 000 программ на 1000 серверах нужно было как минимум 3 высококвалифицированнейших девопса, которые писали кучу описаний как это сделать на Puppet, Salt, Chef, Ansible, да и то не было гарантий, это все тестилось месяцами. То сейчас с Докер даже один квалифицированных девопс может рулить миллионами программ на десятках тысяч серверов. С куда как большей гарантией, что все это заведется нормально.

UPD:

Может сложиться ложное впечатление, что разработчик готовит контейнеры в Докер, а потом передает их админу.
Правильная методология все же другая:

Разработчик отдает весь свой результат в систему CI (обычно через git)
CI на каждый новый коммит делает с помощью Docker образ для тестирования.
Если тесты проходят успешно, то этот же самый Docker образ, отправляется на развертывание в production.
Или, чуть иначе в компилируемых системах, где исходники не нужны в production: в Docker производится развертывание среды для компиляции, а для тестирования разворачивается второй образ с уже откомпилированным добром, который уже отправляется в production.

То есть при правильной огранизации дела разработчик не может/не должен влиять на то, какой будет образ.
А вот в тестовой среде (запускаемом на сервер, недоступном разработчику в больших командах) и в production как раз используется один и тот же образ.

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

Теорию и практику следует правильно дозировать в правильное время. Всегда делал так:
1) Начинаешь изучение новой технологии, больше читаешь, чем пишешь, но обязательно пробуешь задачи, примеры, экспериментируешь до тех пор пока суть не вобъется в голову. Именно поэтому, если я должен выучить новый язык, книгу без задач я не возьму. Здесь цель - понять, как это работает и в каких случаях применяется.
2) Применяешь на практике новые знания, иначе не закрепится. Придумываешь себе задачу на пару вечеров (займет неделю). Больше пишешь, чем читаешь, все проблемы решаешь справкой или погуглив. Здесь цель - выполнить задачу. Не растекаясь на выяснение деталей. Если затык, goto п.1.
3) По окончанию собираешь все мутные темы, с которыми столкнулся, все вопросы, которые решил просто погуглив не разобравшись по сути и goto с ними в п.1.
Это решит твою проблему, когда пишешь в конспект, а не в голову.