index0h

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

Если вы играете с блоками файловой системы на низком уровне, в этом может быть смысл, но тогда не на том ресурсе задаете вопрос)).

В остальных случаях: вы не должны этого хотеть)) Если в принципе подобная ситуация возникает - вы делаете говно.

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

1. Поднимайте уровень, сейчас вы (судя по описанию вопроса) - очень слабенький стажер.
2. Ваш потолок сейчас с точки зрения заказчиков - сайты-визитки.
3. Существует стереотип, что IT === "много быстрых денег, достаточно wiki почитать", это не так.
4. Не используйте слово "простой" и его производные, никогда))

--

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

пошел по пути укрепления навыков PHP ООП, unit тестирования, git и тому подобных технологий, но пока не вижу, где это реализовать(в задачах, которые я листаю на odesk, об этом ни единого упоминания).

А вы их и не найдете)). Вот когда в магазин за хлебом идете, вам важно на каком именно станке мололась мука для хлеба? С unit tests / functional tests / appearance tests / psr-*** / git / code reivew / code analytics tools / doxy gen / ... - примерно тоже самое, всем насрать))
В средних/крупных проектах в этом есть необходимость. В мелких проектах под composer - это тоже полезно, можно получить фитбек от сообщества и улучшить свою же либу))

Осиль twig, или smarty, лучше все равно не напишешь.

Например требуется вывод всех групп из таблицы БД в цикле foreach.

Шаблон работает с БД на прямую? Меняй драг диллера))

Зачем вам это в бэкенде? Вы в любом случае полностью зависите от пользовательской куки. Если человек зайдет с другого браузера вы его отличить не сможете.

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

Товар лучше сделайте чем-то "не делимым", остальное - это уже группы товаров.

Найдите проблему, решите проблему, продайте решение

- Дизайн был сделан в начале 2000-х годов
- Не была продумана структура сайта, расположение контента (куча пустого места на странице)
- Делался студентом за "три копейки"

Для бизнеса важна прибыль, ваши пункты - это хотелки.

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

Этот сайт устарел?)) : https://cmd.fm/79731999

askubuntu.com/questions/50344/how-to-have-two-vers...

Но лучше под каждый проект - окружение на vagrant, или docker

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

В принципе можете еще посмотреть golang.org/pkg/container

1. ТЗ для языка... Может все же "спецификация"? ТЗ - определяет требования к реализации, сроки, требования к окружению, детали реализации..., спецификация не требует этих данных.
2. Если так нужно именно по ГОСТ - в ТЗ описываете, требования, + ссылку на спецификацию (можете ее назвать "объяснительная записка").

Но вообще говоря - присоединяюсь к большинству: бегите.

Гуглите "рефлексия"

Есть 3 кандидата, по описанному в резюме стеку технологий подходят. Как среди них выбрать самого квалифицированного?

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

что мешает кому-то из них, получив доступ к серверу, украсть проект

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

запороть что-нибудь

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

взять проект под свой контроль

Вы шутите?)) Если программист не будет иметь прав работы с кодом - он не сможет ее выполнять. Это как надеть смирительную рубашку на водителя и посадить его за руль.

Вы в любом случае связаны с рисками, правильно составьте договор. Платите достойную ЗП и в срок. Доверяйте его решениям, по реализации кода, для этого собственно вы его и наняли.
Не ставьте над ним кучу менеджеров - профита от этого не будет.
Не оценивайте его работу по тому, что он непосредственно делает (само написание кода обычно только 10% рабочего времени, остальное в большей части - "думалка"), оценивайте результат.

Можете в сторону catberry посмотреть

То, что вы ищите - называется issue tracker, или bug tracker, или task manager.

Обычно это /var/www/html/{main.domain.of.site.here}/

1. Под какую нагрузку рассчитываете?
2. Чем не подходит вариант нанять опытных программистов?

Для "лишь бы было" учить в принципе не стоит, дешевле нанять фрилансера.

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

Чем вас QML не устраивает? Многие особо не парятся и интерфейсом делают embedded браузер (часто из коробки своего же фреймворка). У вас не получится создать систему столь же удобную под каждую из платформ, чем аналоги заточенные под эти платформы.

Так уж случилось, что мир движется все больше и больше к чисто сетевым технологиям - там в принципе не важно, на чем ваш бэкенд. Взгляните, как строится frontend во многих go проектах, например consul, etcd, ... либо в ELK стеке. По сути есть некие серверные системы, предлагающие некое API, вы сразу можете им пользоваться, если же необходим GUI - вы устанавливаете (или просто включаете) браузерное SPA, которое будет работать с тем же сервисом, но с человеко-понятным интерфейсом.