alexandermor

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

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

Вариантов много:
1. Выполнение заказов на фрилансе
2. Заработок на своих сайтах
3. Арбитраж трафика

Но опять же для всех вариантов нужны знания.

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

Если человек работает в фотошопе - то он дизайнер , и работать дизайнером он будет вне зависимости от наличия фотошопа или умения работать в нем. Программист может расписать алгоритм без использования компьютера. И так далее.

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

1. Возраст не имеет значения.
2. Если нет навыков, тогда что еще Вы можете предложить рынку в обмен на деньги?

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

На перфокартных системах хранения данных одна строка записывалась на одну перфокарту, поэтому строка была заданной длины, по количеству колонок (обычно 80). Строки короче добивались пробелами, а строки длиннее обрезались. Разделителя строк не было, а неявный перевод строки предполагался через каждые 80 символов. Некоторые ранние мейнфреймовые операционные системы переняли это для хранения текста в файлах, где уже не было естественного ограничения на длину строки. Упорно форсить это начали IBM

С помощью Eclipse я написал целую игру и скомпилировал, получилось 270 КБ. А с помощью Android Studio написал простую "Hello World" и тоже скомпилировал, поучилось 900 КБ. Хотя Android Studio использовать приятнее, чем Eclipse.

Для начала нужно очень хорошо знать Java Core (самое главное - коллекции) и неплохо знать Spring. Так же хорошо бы знать какой-нибудь web-фреймворк типа Spring MVC, знать, что такое JSP. Плюс - знание Hibernate. С таким набором знаний можно быть уверенным, что найдете удаленную работу.

Так же важно знание английского хотя бы на уровне B2

Сначала надо сказать что система версионирования файлов ни коим образом не заменяет среду для разработки/тестирования (в плане веб сервера или базы данных), это просто дополнительный инструмент. В первую очередь система версионирования даст доступ к комментированной истории изменений. Это может пригодиться, например, когда вы ищите баг который вы внесли когда-то правя другие баги. Так же версионирование помогает, если вы какое-то время не занимались этим проектом — легче вспомнить на чём вы остановились. Так же станет легче развивать проект в независимости от версии вашего кода на «боевом» сервере (например сделать live и development ветви). FTP upload версионированию не помеха, это абсолютно разные вещи. Базу данных можно версионировать отдельно, но обычно версионируется только основная структура базы для деплоймента «с нуля» (например .php файл с create стейтментами). SVN или Git (или другой CVS) это уже больше выбор по вкусу/нужности плюшек. Безусловно любая CVS будет нужна если над проектом вдруг начнёт работать кто-то кроме вас.

Git — это инструмент с определённым функционалом и не более. Способы его использования ограничиваются вашей фантазией. Необходимым и незаменимым он становится при работе в команде.

Примеры же использования в одного:
1)Работайте так же с удалённым сервером (netbeans это позволяет), проект свой разбейте на пару версий — dev и production, инициализируйте в dev репозиторий, работайте с версией в dev, а по окончании этапа работы делайте commit (сохранение наработок в git) и выкладывайте в production.
2) локально делайте копию репозитория git, подключайтесь к базе удалённо, затем несколько наработок из разных копий (с домашней машины и рабочей, ноута...) сводите в один проект, автоматически или руками разрешая конфликты.
3) Ну, а возможность быстро откатиться до определённой версии — бесценно! Кстати, в каждой копии репозитория будет полная история изменений.

Управление историей. Нетбинс любит терять историю, реально рассчитывать на нее нет смысла. А тут это основа.
Ветвление и слияние. Когда нужно делать большое изменение, а система уже в продакшене, и ты вынужден ее поддерживать, то сделать ветку, и править на ней, а потом объединить ветки, да так чтобы не затереть изменения в обеих — почти невозможно когда нет системы управления версиями.
Совместная работа. Пропадает всякий бред типа в аське писать мол не трогай такой-то файл, я его правлю…
Сотни мелких коммитов с описаниями. Т.е. делаешь изменения, и сразу описываешь, и сразу видно в каких файлах это было и когда… Помогает в расследованиях, в документировании.
Возможность контролировать «что изменилось». Анекдотичный случай — я как-то в четыре часа ночи решил переименовать в одном классе модели поле desc на _text. Оно фигурировала в нескольких сотнях классов, поэтому я использовал поиск и замену. Полуручную.

Через месяц у меня выплыл глюк с сортировкой данных. Оказывается при поиске я случайно заменил desc в запросах в ORM. Был бы тогда GIT да получше покрытие тестами — не пришлось бы два часа искать причину. Я бы увидел, что у меня есть изменение в таком-то файле, а оно там неуместно…

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

Суть в том, что вы можете четко контролировать в какой момент получилось плохо. Вы можете проследить цепь событий которая к этому привела. И главное — вы можете спокойно откатиться на тот момент когда все было хорошо.
В случае с гитом и доступом к ssh вы делаете так, на локальной машине
git push
на сервере
git pull
И собственно все!
Если вы работаете с композером, то можно например настроить composer up на выполнение git pull перед обновлением зависимостей. Таким образом вы весь проект приводите к актуальному состоянию одной командой.
И да, у вас по хорошему должна быть отдельная БД, в которой лежат тестовые данные, ведь вам важны схемы таблиц, а не их содержание по ходу разработки?
Также по поводу гита — представьте что вы на столько любите женщин, что хотите встречаться с несколькими одновременно. В реальности трудно удержать более n-кол-ва паралельно, они столкнутся и вам будет плохо. А в git вы просто создаете ветки и то процедуры слияния они друг о друге не подразумевают. По хорошему каждая фича вашего приложения должна создаваться как отдельная ветка(branch), таким образом вы сможете просматривать историю разработки конкретно этой фичи отдельно.
Сумбурно, но это ощущение после полугодичного использования гита.
PS также представьте что вы сейчас вероятно один работаете, а каково работать таким образом в команде. Если это делать без VCS — высока возможность перезаписать файл который только что изменили и тд и тп