Денис Туренко

Могу посоветовать написать техническому директору на ez@megaplan.ru или через фейсбук, он отвечает.

Есть онлайн генераторы, поколдуй с ними.

Юзайте вот этот: github.com/jamm/Memory/blob/master/RedisServer.php (его написал я).
Он тоже есть в официальном списке, проверен на высоких нагрузках, поддерживает все фичи новых версий Redis.
Не требует Phpredis.

Практика показывает, что взломать можно что угодно, так что не парьтесь особо. Главное, чтобы все стандартные меры безопасности были соблюдены. Тут в конце приведены базовые рекомендации safesearch.ya.ru/replies.xml?item_no=120

Нууу. Книжек я не читал, но если тут будут очень будет полезно.

> что-бы не создавать себе грабли в истории и не получить подзатыльник от коллеги?
Ну, надо договориться в начале со всеми, как вы будете это делать. А то странная вакханалия подзатыльников по всей команде начнется =)

Как у нас заведено:
У нас коммент разделяется на несколько частей.
1) условное слово, что сделано. fix (исправлено), unstanle (означает, что обновлять на рабочий сервер это версией нельзя)
2) на новой строке ссылка на багтрекер, в которой описана проблема ( http:// mantis/issue/id условно), и айди комментария(ев) в вопросе.
3) Возможные комментарии, через черточку на новой строке каждый
— коммент1
— коммент2

====== Пример 1

fix
http:// ....
- решено то
- решено сё

====== Пример 2

unstable
http//..... 1233, 1235
- не исправлена на чистовую версию синхронизация

====== Пример 3

fix
http//..... 1233, 1235</code>

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

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

Когда я работал на фриласне с другими удаленными участкниками проекта. Возникала таже проблема, только с другой стороны. Было сложно выяснить каике-то детали ТЗ или задач в трекере.

Сайчас мы работаем с удаленным заказчиком. Вобщем проблема коммуникации весьма заметна.

Гораздо проще выяснить детали у менеджера или программиста сидящего в соседней комнате, чем получить туже нифу у человека за 2000 км от тебя. В скайпе легко общаться на житейсике темы, но когда дело доходит до кода, диаграм и спецификаций, то в скйпе нет удобного механизма для этого. В живую можно тыкнуть пльцем в монитор, показав кусок кода, начертить диаграмму на доске или бумаге, объяснив на пальцах, что это за квадратики и стрелочки.

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

Если речь идет о веб студиях или подобных компаниях, то у них как правило есть опыт работы с фрилансерами. Большинство предпочитает сотрудников в офис.

В Slim нету мультиязычности. В Slim нету ORM.

Мультиязычность — можно самому.
ORM — j4mie.github.com/idiormandparis/

Я принимал участие в разработке Slim, поэтому выбрал бы его :)

Я думаю DokuWiki Вам должен подойти, хорошо написал + большое кол-во плагинов

ОФ сайт www.dokuwiki.org/dokuwiki

blueimp.github.com/jQuery-File-Upload/

Отичный вариант.

Нарушением уровня абстракций, насколько я понимаю то, что вы вкладываете в понятие уровня абстракции, будет факт несогласованности интерфейса класса. Если у вас есть методы из названий которых следует, что они относятся к разным уровням абстракции, вы нарушили абстракцию класса. Другими словами, если в одном классе есть методы getCount и getCountOfFlat — на лицо нарушение абстрагирования. Появление таких методов вероятно при наличии наследования, которое я считаю исключением из правил.

На сколько я понимаю, из курса ТСПП, уровень абстракции — абстрактная величина, и не может быть вычислена.

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

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

P. S. Никогда не встречал понятие уровня абстракции за пределам контекста декомпозиции, может не правильно понял, следовательно, не правильно ответил :(

Если подумать о теории и космическом то:

В моем видении все просто.

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

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

Тут есть ссылки на DIN, ГОСТ лучше искать на gost-rf.ru.

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

Лично я небольшие вставки делаю прямо в коде. Особенно если это всякие плагины :) Небольшим вставкам в большом файле плохо — они теряются на фоне других и их зачастую труднее поддерживать.

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

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

В общем случае только поиск человека и заявление от него на передачу домена.
В частном случае можно попробовать через суд. Но на каком основании — это сложный вопрос. Обычно отсуждают на основании имеющейся торговой марки.

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

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

Если домен регистрировался хостером (а раз вы продлеваете через него, то, скорее всего именно так ) — пишите ему тикет «Хочу перенести доменное имя к другому регистратору». Хостер скажет какие документы необходимы, возможно скан паспорта. Ну и скан чьего паспорта скажет, естественно.

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

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

Однако есть ряд моментов, которые носят информативный характер, но их стоит учесть.

1. Инвестор в чем-то заинтересован, ваша задача — попытаться разобраться что именно его интересует. Понимание истинных намерений упростит вам жизнь и может уберечь от неправильных решений
2. Многие считают, что инвесторы дадут вам чемодан с деньгами, которые вы можете тратить куда угодно. Нет, вместе с деньгами придет жесткий контроль и ответственность. Нужно понимать, что вы можете по неосторожности потерять все, и комманду, и проект, и остаться еще и без денег, да еще и должны останетесь. Поэтому не рисуйте себе Майбах во дворе, мечтания приведут вас к долгам.
3. Нужно быть психологически готовым к тому, что инвестор не покупает вас с потрохами, а всего лишь дает вам ресурсы, которые вы должны вернуть с неким процентом. Инвестор, который ведет себя как рабовладелец вам не нужен, бегите от него подальше и без оглядки
4. Инвестирование может быть двух видов — покупка акций и соучредительство с последующей накачкой денег. Акции бывают двух типов — которые дают право на управление компанией, и которые не дают такое право. Если инвестор получает контроль над вашей компанией, то вам придется мириться с его способами ведения бизнеса. Наличие денег в руках не означает контроль.
5. У вас всегда должен быть запасной план.

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

Отпишусь пожалуй о своем опыте.

Ситуация схожая, но изначально товаров нужно было 250 кпозицией. Анализ коробочных решений (который не я делал) показал, что либо коробка на таких объемах не может гарантировать быстрой работы, либо производители коробки хотят таких денег на энтерпрайз, что пилить свое дешевле. Собственно чем в настоящее время и занят.

Свое требует времени, но позволяет полностью контролировать движок и быть точно уверенным в нагрузках, которые он потянет. Кроме того гарантирует более выгодную схему модификации движка, т.е. супорт движка становиться проще как технически, так и финансово. А сапорт движка собственно и есть основная статья расхода для ПО. Что удалось получить на данный момент, так это каталог. Т.е. дерево категорий, карточки товара, админка для менеджеров (создать товар, добавить к товару атрибуты). Количество товаров не ограничено, количество и тип характеристик товаров так же не ограничено и ведется через админку (т.е. дополнительно кодить ни чего не нужно). Нагрузочные тесты показали, что при ~200 МБ ОЗУ под PHP движок держит 300 запросов/сек (при попадании в кэш страница генерится за 10-15 мс) долговременно (т.е. где-то до 25 миллионов хитов в сутки) и может держать пик в 1000 запрос, но не дольше 5 сек, потом начинаются валится 50-ые. Это при каталоге в 250 кпозиций по 10 характеристик на товар. В целом вся связка (веб сервер, субд, кэш) кушает 1-1,5 ГБ ОЗУ. При этом полная развязка данных и шаблонов, поэтому можно иметь сколько угодно вариантов верски, т.е. ни какой смеси из php+html нет.

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

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