V Sh., уверены, что не подходит? Я бы советовал с ними пообщаться, как минимум. Вполне возможно, что они могут выступить посредниками и сильно облегчить бухгалтерскую сторону операции.
rPman, новичок, тасуя DE в убунте, может получить нерабочую систему. А главное - на хрена козе баян? Зачем новичку вся эта вольтижировка, если его устраивает то DE, которое ставится по умолчанию?
Что деривативы - один и тот же дистрибутив, я учел - и дал ссылку на Xubuntu, в котором настройки от юзера не скрывают...
The_XXI, можно настроить передачу php фвйлов на обработку Апачу, который их уже, в свою очередь, передает PHP-интерпретатору. Это тоже настраивается в nginx, так что без его настройки все равно не обойтись.
3.1) Но при этом не упарываться делать такой же крутой интерфейс, как у образца. Времени сожрет - жуть, а потом все равно отправится в корзину. На начальном этапе - чем топорнее, тем лучше.
Модератор, ну нет же, это вообще не вопрос какой-то там относительной крутизны и шифгреттора.
Это конкретный участок образовательной кривой: любой начинающий программист поначалу говнокодит, и его просто необходимо поддерживать в стремлении расти. В том числе - и тыкая носом в говнокод. Для его же будущего.
Модератор, при всем уважении к правилам, говнокодер - это таки термин, а не экспрессивная лексика. Ни я, ни автор ответа, буде опытный человек по делу назовет нас говнокодерами, не воспримем это как личное оскорбление. Это общепринятая в сообществе оценка профессионализма. В случае ТС - совершенно однозначная, кстати.
Erimax, ни в коем случае! Немедленно беги с этого сайта! Здесь тебе осмелились после того, как разжевали элементарную задачу, высказать свое мнение о том, что ты как программист, очевидно, пустое место. Разве так можно?
Михаил, отправлять джуна вместо говнокодинга читать Мартина с Макконнелом бесполезно - для понимания изложенного в этих книгах нужен тот самый практический опыт, который без говнокодинга ну никак не заработаешь.
Михаил, ну, так на небесный инструктаж рассчитывать не приходится - нужно самому сесть и наработать этот самый опыт, ковыряясь в архитектуре и постановках задач. Без практического опыта никакие самые правильные архитектуры просто-напросто не зайдут. А без опыта ошибок не появится навыка постановки задач.
Jeff_Parker, вам сейчас важно не растекаться по древу - как сделать оптимально и навеки. Хрен вы сделаете так сразу, без опыта. Вам нужно не бояться сесть и начать писать, как получается.
Но стараться не смешивать - то есть делать API настолько абстрактным, насколько это вообще возможно, чтобы работу БД за ним можно было однажды взять и переписать полностью, не меняя ничего в API.
И когда что-то вас перестанет устраивать и появится понимание, как это можно сделать правильнее - выкинуть старье и все переписать. Уже понимая, что, зачем и почему именно так делается в вашей системе.
Jeff_Parker, главную схему я вам и написал - упирайте все в API, это даст необходимую гибкость и возможность использования его в любых ситуациях.
Естественно, у того API надо сразу решать схему авторизации, формат обмена данными и проч., но для этого можно поизучать любое открытое хорошо написанное API и творить по аналогии. Выбор конкретной схемы некритичен, важно только, чтобы она была единой, консистентной и открытой, то есть предусматривающей расширение без костылей.
С написанием MVP и разгребанием рутины перевода требований бизнеса в формализованную бизнес-логику может справиться и джун. Небыстро и неоптимально, но может.
