Максим Гаврилов

Если вдумываться в то что может влиять то может повлиять и атмосферное давление на принятие решения по выбору подрядчика по этой причине думать что может влиять - не советую. Если рассматривать по важности то первое и может быть единственное что действительно влияет - это портфолио. Если его вообще нет то ожидать какой-то приличный проект бессмысленно потому что все таки дизайнер без портфолио не тот дизайнер который нужен в коммерческой разработке. Если разобраться "почему?" то дизайнер это увлеченный творчеством человек и он постоянно что-то (рисует) дизайнит потому у него должны быть хотя-бы некоммерческое портфолио. А дальше все просто - заказчик смотрит на портфолио и если для его проекта подходит ваше мастерство то идет смотреть потянет его или нет. При достаточном портфолио задаваться вопросом почему столько стоит мало кто будет. О том как найти заказчиков ?! - участвовать в обсуждении заказа. Какой он именно (фиксированный, почасовый или еще какой) - никому нет дела. Действуйте.

Я бы начал разговор с менеджмента. Конечно git хорошая, полезная штука, но тем не менее git это система контроля версиями в первую очередь, а потом уже стоит говорить что при разработке командой контроль получается у разного программиста своя версия и дабы кто не слил все свои наработки на dev сервер которые заменят разработки соседа который вылил все часом раньше. Можно даже сказать что гит не заменим, но также с гитом можно работать и при одиночной работе и в этом он тоже очень хорошо поможет контролировать процесс заливки файл на сервер и внесение изменений в файлы. Поэтому хочу также сказать что внедрение одного гита конечно упростит работу, но не так что все станет кул.

Говоря о менеджменте командной разработки можно говорить о том что должен быть тим-лид (идейный вдохновитель проекта) который будет нести ответственность за его реализацию, что должен быть менеджер проектов в проекте который будет переводить с языка клиента на язык тим-лида потом объединять мнения тим-лида с мнением клиента и выписывать user-story для программиста. Однако и многое другое сказано в описании методологий командной разработки используя гибкую систему Agile с методологиями Scrum, Kanban. Думаю это то, что надо изучать для орагнизации командной работы над проектом. Тех. сторона (git, jira) процесса тоже важна, но если организация будет успешно выполнять проекты используя ftp и при этом не будет вопросов вроде ты заменил мои новые файлы на свои, а на сервере они были в единственном виде. И также не будет вопросов о безопасности где кто-то с ftp сольет файлы себе на флешку и уташит домой то никто из клиентов против не будет. А если будет методология водопад вместо Agile то клиент может пойти в другую контору с Agile потому что это реальный бонус для клиента и разработчиков.

Если уж совсем все хреново то как крайний вариант можно нанять опытного тим-лида с опытным менеджером проектов которые наладят весь процесс Agile с методологиями Scrum, Kanban для вас.

P.S. мы тоже на работе используем NetBeans но вместо ftp - git.

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

Чтобы все стало реально думаю надо наличие собственных разработок. Не то, чтобы бы были в наличии программы управления ядерным реактором, но вот программы выполняющие простые вещи (копирование файлой из списка .m3u, крестики-нолики, сапер, прогнозирование стоимости товара на основе алгоритма МНК с построение апроксимирующей кривой и подсчетом контрольных параметров, прогнозирование данных на основе алгоритма Ньютона, решение задачи поиска наименьшего пути в графе и др. прикладные студенческие программы), быть должны. Тогда тим-лид произведет ревью и если код покажет уровень увлеченного начинающего программиста - то дело сделано - работа получена. Без собственных наработок считаю выполнение задачи просто нереальной - надо будет ждать наличия диплома на руках.

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

Но в любом случае дедлайны имеют место быть потому что человек заказывающий ПО как правило ничего не смыслит в программировании, но он хочет ожидать когда будет предоставлен продукт.
На бытовом примере можно объяснить так: вы покупаете холодильник в магазине с доставкой и не оставите же вы холдильник в магазине сказав - да, на доставку надо время так что привизите его как будете готовы, вместо простого вопроса: в течении какого времени будет осуществленна доставка?!

На первый взгляд будет достаточно 3х таблиц: вопросы, заданные вопросы, предоставленные ответы.
Хотя я бы посоветовал обратиться к архитектору баз данных с заданием на разработку, а самому тренироваться на чем-то менее критичном.

Что если применить #define для определения константы?

Ну как тебе сказать?! Сначала бизнес логика, потом предметная область, потом реализация предметной области в классах (ER диаграмма) что даст представление о БД которая разрабатывается после и на основе предметной области. Далее мигрируем диаграмму БД в код для конкретной СУБД. потом классы предметной области дополняются функциональностью и параллельно разрабатывается визуализация (фронт-энд). Потом наступает момент интеграции где предметная область интегрируется с БД и фронт-энд интегрируется с бэк-эндом и все уходит на тестирование. Как правило это все разрабатывается в один момент времени потому что работает команда, а если же трудишься и стараешься сам, то надо распределять время и заниматься часть дня тем, часть дня сем, и еще часть дня вот этим и так по кругу стремясь использовать спиральный метод разработки ПО с принципами Agile. Водопад не рекомендую.

Вычисление значений функции y=1/x.

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

https://ru.wikipedia.org/wiki/%CA%EE%E4%E5%F0

Лучше изучать материал который дается для изучения Java при обучении перед получением сертификата. Учишь, сертифицируешься, учишь сертифицируешься и работать.

Как прeодолеть зону комфорта

По русски это звучит так: "глаза бояться, а руки делают"

Массив в БД? А как же нормальные формы?! Наверное надо менять архитектуру

Что если сделать такую структуру папок:
/laravel
/helpers
/domain
-----/www
-----/subdomain1
-----/subdomain2
-----/subdomain3
Все что в папках www и subdomain обращаются за файлами в папки laravel и helpers которые в единственном экземпляре.
А делим все апачем где в VirtualHost параметр DocumentRoot определяем для каждого домена и субдомена соответственно:
/var/www/laravel_project/domian/www
/var/www/laravel_project/domian/subdomain1
/var/www/laravel_project/domian/subdomain2
/var/www/laravel_project/domian/subdomain3

:) Вы про сайт визитку? Нет?! Ну ладно. Берем одноклассники и представляем что каждая отдельная функция это отдельный сайт. Размер такого сайта-функции получится с размер сайта визитки. Т. е. делаем множество сайтов визиток и объединяем их в одну структуру.

Получается метод поедания слона: если вы не можете съесть слона целиком, съешьте его частями :).

Подожду пока свой код покажешь :)!

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

Мне больше нравятся задания типа: сделать телефонную книгу, набросайте небольшую доску объявлений и т. п.

Но задание подобное вашему тоже имеет место быть. Кроме того: не факт что свой гит смотрел кто-то из разработчиков, может быть это был HR мэнэджер для которого код ничего не значит, а выполненное тестовое задание это кул. Помните об HR.

Лучше не терять соединение:

$this -> pdo = new \PDO(
                "mysql:host=" . $this -> DB_HOST . " ;dbname=" . $this -> DB_NAME . ";", 
                $this -> DB_USER, 
                $this -> DB_PW,
                array(\PDO::ATTR_PERSISTENT => true)
            );

Вместо Шилдта я порекомендую Шилтда! В крайнем случае, если Шилдт вообще ни в какую я порекомендую книгу Шилдта. Могу еще Лукяненко порекомендовать потому что программирование изучать по диагонали всись и вкось не получится. Программирование это довольно муторная, довольно скучная профессия в которой надо быть внимательным и читать строчку, за строчкой, страницу за страницей, главу за главой, внимательно вникая в суть написанного, перечитывая непонятные места и разбирая из с помощью гугла.
А у Лукьяненко вполне приличная современная фантастика! Можно весело и не скучно провести досуг.

Поэтому либо Шилдт либо Лукьяненко.

П.С. Шилдт это одна из самых легких книг которые читаются на одном дыхании.

Это как в фильме "Очень плохая училка": "живешь, учишься, добиваешься успеха, а потом понимаешь что массажист это самая лучшая в мире профессия и идешь по ней работать".

Все в жизни бывает.