evilbloodydemon

Регулярное выражение — это вызов функции, а это более затратный процесс.

NOSQL БД не становятся популярными, а занимают свою нишу.

NOSQL никогда не заменит реляционные SQL. Есть направления, в которых NOSQL эффективны, и есть другие направления, в которых SQL эффективна. Сейчас идёт процесс перераспределения сфер применения этих решений.

Когда мы писали проект на Zend, то использовался phpcs (у него есть поддержка разных стандартов, среди которых и Zend). Этого хватало, а раз в месяц просто последнюю ревизию правили ручками, при правильно настроенной IDE править руками если и придется, то очень мало.

Присоединяюсь. Копипаста быть не должно, общие фрагменты во view выносятся в отдельные подключаемые файлы. в CakePHP эта структура называется elements book.cakephp.org/1.2/en/view/97/Elements в других фрэймовках есть свои аналоги

Идея написать «написать что-то вроде CMS на очень крутом, на мой счет, фреймворке Yii» порочна изначально.
Дело тут не в желании написать CMS и не в Yii, а в том, что писать CMS имеет смысл когда сформулирована некая идея, зачем эта CMS нужна и чем она будет выгодно отличаться от сотен имеющихся. То, что она будет написана на основе какого-либо фреймворка, отнюдь не решающее достоинство.

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

тогда пусть они всплывают вниз ))

Э. Фримен, Э. Фримен, К. Сьерра, Б. Бейтс. Паттерны проектирования.
www.ozon.ru/context/detail/id/6108824/

Описаны те же паттерны, что и у ГоФ, но более доступно. Для начинающего самое оно.

Ну и конечно:
С. Макконнелл Совершенный код.

Мартин Фаулер. Архитектура корпоративных приложений.
ISBN 5-8459-0579-6, 0-321-12742-0; 2007 г.

На блоге какого-то C++ программера прочитал типа такого ответа… «Программист пишет познавательные сказки для компьтеров и они стараються поступать также, как и написано в книге» :)

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

Однако, вроде как посмотреть всё ж при желании можно с помощью git log –graph — однако это немного не то, что нужно…

Какую машину выбрать чтобы ездить?
Смотрите на свои возможности и требования. Сначала определитесь с языком разработки — далее копайте уже исходя из выбранного языка.
Далее уже смотрите на то, что более привычно и знакомо — для php куча фреймворков, которые уже упоминали выше. Если вам надо решение под ключ — Social Engine.

Хм, интересно, а как с виртуальными картами?

Я сейчас обучаюсь в автошколе. Мы занимаемся по диску «Автошкола МААШ: подготовка к теоретическому экзамену в ГИБДД версия х3». Ну я конечно же скачал с торрента его, очень удобно заниматься по нему. Сразу и теория и тесты. Советую.

1. Одна из лучших IDE(если не лучшая) — visual studio + R#
2. JIT (скорость)
3. Динамично развивающийся язык (в отличие от той же явы и кривой поделки — php)
4. Активное сообщество + неважно под что ты пишешь, все разработчики(десктоп, веб, мобильные платформы) объединены.
5. Майкрософт за спиной с его гигабаксами. Это значит продвижение технологии на всех уровнях, встраивание фрэймворка в венду, создание облачных сервисов, поддержка сообщества(поощрение активных членов, куча различных конференций, издание книг и т.д.), интеграция с другими продуктами(iis, office, SQL Server etc).
Если на каком-то участке намечается отставание, МС позаботится о том, чтобы его подтянуть(как было с ASP.NET — выпуск MVC).
6. +для программистов — возможность перейти с ASP.NET на дестктоп, телефоны, приставки, микроконтроллеры, Silverlight… В общем куда угодно, инвестируя меньше времени на изучение, за счет единой платформы.
7. Все технологии развиваются очень и очень активно. Silverlight вроде бы совсем недавно появился, уже есть 5 релизов, mvc — 3, и не за горами 4-ый. В каждом релизе появляется много интересных фишек и вкусностей упрощающих разработку.

Из последнего очень заинтересовал knockout.js.
И, как следствие, backbone.js.
По обоим есть даже несколько статей на хабре.
Довольно интересные штуки :)

Мне кажется, есть такое заблуждение, что выкладывание проекта в открытый доступ привлечет к нему активное внимание, в том числе и нежелательную критику. В психологии даже термин есть для этого: spotlight effect.

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

— Исправьте откровенные косяки, если такие имеются.
— Сделайте небольшой файл README с описанием возможностей и правильного способа установки
— Выложите на github. Публикация на github не накладывает серьезных моральных обязательств :)
— Если стыдно сообщать о проекте всем, расскажите только своим друзьям. Вдруг им понадобится и понравится.

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

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

Это какая-то мерзенькая реклама. Я долго не мог одуплить, что происходит.

Highload обычно употребляется в смысле — «умение горизонтально масштабировать веб-проект до любого теоретически достижимого числа клиентов».

По численным именам по мне лучше использовать более конкретные имена, к примеру устоявшееся C10K problem, или «как работать с 10000 одновременные коннектами пользователей» на комп. При работе с торрент-анонсером, такая проблема, к примеру, возникала.

А чем аутсорсинг вас не устраивает? Я единственный раз поработал несколько месяцев в родном городе, будучи еще студентом — результат плачевен, с тех пор работаю исключительно аутсорсером. Переезжать никуда не хочу — моей зарплаты хватает с лихвой, чтобы обеспечить в нашем Мухосранске меня, жену и маленького ребенка.