Вы не путайте игры и сложные порталы. Я немного знаком с игровой архитектурой, она совсем другие проблемы решает.
Популярные ныне игры для социальных сетей представляют не-вполне-тонкий клиент на Флеше, с достаточно простым бекэндом на сервере. От последнего требуется в основном а) сохрание/загрузка состояния клиента из БД; б) кеширование этого самого состояния для пущего ускорения в) запуск периодических задач. Усе. Сиди да решай проблемы производительности.
Бекэнд же любого приличного портала на порядок сложнее и больше.
С точки зрения разработчика обилие фреймворков подчеркивает проблему выбора инструмента и проблему освоения новых в той же области, того явно не требующей.
Можно привести примеры популярнейших языков, где 1-2 ключевых фреймворка в целевой области задают дефакто стандарт, а менее популярные отвечают за эксперименты и пробы. Скажем JQuery в js, Django в Python, RoR для Ruby, Spring для Java (как традиционный выбор для некорпоративных решений) и так далее.
Позвольте вас поправить. Скорее должно звучать так «в некритичных системах, создаваемых небольшими командами, гибкие методологие вытесняют классические».
Реально же IBM, MS, множество средней руки Java-аутсорсеров проектируют свои проекты до посинения.
Причем оба подхода ошибочны, как оба — верны. Крупные системы надо регулировать и сверху вниз, и снизу вверх. Нельзя проектировать архитектуру, не вникая в нюансы; как нельзя сохранить стройность системы, не посмотрев на нее «с высоты архитекторского полета».
Умение держать баланс — важный для архитекторов/тимлидов скилл.
После «нормальных» контор типа описанной вами люди перестают разбираться в том, что делают. Иногда полезно знать архитектуру разрабатываемого ПО и сопроводительного софта.
А то я запарился своему приятелю-явисту (!!!) объяснять, как правильно организовать сборку проекта, continiuos integration и бла-бла-бла. Человек без Eclipse — как без рук, даже конфига ant/maven не способен написать.
Вы, как сторонник CLisp, должны были видеть статьи Стива Егга на эту тему. Вспомните его же сравнение этого языка с Ходячим Замком Хоула :)
Язык большой, огромный, невероятно гибкий… И я это отлично понимаю как емаксер, лиспер, еще в универе в качестве хобби изучал разные языки, больше всего — функциональные.
Но… Гибкость и многогранность — это проблема. Средства должны быть а) ограниченные б) простые в) универсальные. Иначе в больших проектах программисты просто-напросто перестают понимать друг друга.
Я согласен с вами в том смысле, что богаче и выразительней Лиспа языков нет. Однако же, уверен, что вы все эти цветастые средства не используете в работе. Если вообще работаете с этим языком на дневной работе!
С другой стороны, ваш оппонент, нахваливая гибкость С++ на примере boost замалчивает тот факт, что boost не только не входит в сам язык, но и изрядно усложняет и без того непростую базу. А уродливые макросы… А незабвенные извращения Александреску… И приличные программисты очень, о-о-о-очень, ОЧЕНЬ аккуратно ко всему этому относятся.
Я, честно говоря, постоянно работаю со скрытыми папками в Линуксе; частенько делаю всякие find -name и прочее, и в целом не люблю, когда в проекте есть лишние файлы. Считайте это моим идеализмом.
В общем, могу сразу обозначить для вас слабые стороны.
1) неприятная работа с большими бинарниками по понятным причинам;
2) пустые директории или файлы в силу архитектуры git невозможны;
3) по первости несколько путает терминология git;
4) роль репозитария несколько уже по сравнению с svn. Если в svn в структуре репозитария запросто можно хранить вообще весь проектный мусор (бинарную документацию pdf или doc, к примеру; исходники сопровождающего проект сайта), то git хотя и позволяет вытаскивать отдельные файлы или директории, но не предназначен для этого. В svn же бранчи — это просто папки, все равно, что хранится.
Из преимуществ.
1) все, что хочется делать с кодом или текстом — в git лучше, быстрее, разнообразнее. Это можно понять и оценить, только поработав; обычно пользователи svn слабо представляют себе разнообразие альтернативных методов работы с хранилищами кода.
2) конечно же, полноценная работа без Инета в силу распределенной природы.
3) вы указали хостинг репозитариев. А вот у меня, к примеру, есть две машины: офисная и домашний ноут. И я запросто делаю синхронизацию кода в любую сторону, без посредников, платных или бесплатных.
Далее мысли в целом по текущему положению дел с системами.
За распределенными репозами образца git — будущее. Это поняли уже все. Даже Фаулер где-то писал про неизбежность постепенного перехода, хотя в первых блог-постах на тему сильно сомневался. Конечно, переход с svn на git, hg, bzк не повысит вашу работоспособность, но определенно упростить жизнь.
Ветки, конечно, в svn есть. Но каждый раз для переключения вы будете тащить другую ветку с сервера? И все свои локальные эксперименты хотите пихать в главный репоз? Да и незаконченные изменения отложить на время в сторону так легко тоже не получится.
Вообще, у концепции ветвления в svn принципиально другой смысл, хранятся они по-другому и используются значительно реже.
Но, признаюсь, жил бы и жил я нормально безо всех этих радостей, если бы не было двух вещей в svn:
1) по проекту разбросан мусор в виде .svn в каждой директории
2) НЕУДОБНО для каждого мелкого личного проекта заводить центральный репоз, потом из него в директорию проекта checkout делать.
А еще в git что очень хорошо, так это удобство настройки файлом .git/config. Переехал с ноутом в другую локальную сеть — достаточно просто сменить адрес условно-центрального репоза — и дальше в работу.
Ну и мелочей всякий масса, типа удобных альясов или конфигурируемости ключевых команд, бла-бла-бла. Это уже для гуру вкусности.
Сейчас же даже на работе уже настроил гейт от git к корпоративному svn и пользуюсь в свое удовольствие.
Я не зря сослался на org-mode. Там и теги, и приоритеры, и календарное планирование, и таймеры, и чебоксы, и экспорт куда угодно, и таблицы… И, что немаловажно, возможность ничего из перечисленного не использовать…
Популярные ныне игры для социальных сетей представляют не-вполне-тонкий клиент на Флеше, с достаточно простым бекэндом на сервере. От последнего требуется в основном а) сохрание/загрузка состояния клиента из БД; б) кеширование этого самого состояния для пущего ускорения в) запуск периодических задач. Усе. Сиди да решай проблемы производительности.
Бекэнд же любого приличного портала на порядок сложнее и больше.
Можно привести примеры популярнейших языков, где 1-2 ключевых фреймворка в целевой области задают дефакто стандарт, а менее популярные отвечают за эксперименты и пробы. Скажем JQuery в js, Django в Python, RoR для Ruby, Spring для Java (как традиционный выбор для некорпоративных решений) и так далее.
Не причины ли это общей неприязни к языку в мире разработчиков?
RUP не RUP, а IBM — практически вотчина UML-проектирования.
Реально же IBM, MS, множество средней руки Java-аутсорсеров проектируют свои проекты до посинения.
Причем оба подхода ошибочны, как оба — верны. Крупные системы надо регулировать и сверху вниз, и снизу вверх. Нельзя проектировать архитектуру, не вникая в нюансы; как нельзя сохранить стройность системы, не посмотрев на нее «с высоты архитекторского полета».
Умение держать баланс — важный для архитекторов/тимлидов скилл.
После «нормальных» контор типа описанной вами люди перестают разбираться в том, что делают. Иногда полезно знать архитектуру разрабатываемого ПО и сопроводительного софта.
А то я запарился своему приятелю-явисту (!!!) объяснять, как правильно организовать сборку проекта, continiuos integration и бла-бла-бла. Человек без Eclipse — как без рук, даже конфига ant/maven не способен написать.
PostgreSQL — вот это коммьюнити.
Язык большой, огромный, невероятно гибкий… И я это отлично понимаю как емаксер, лиспер, еще в универе в качестве хобби изучал разные языки, больше всего — функциональные.
Но… Гибкость и многогранность — это проблема. Средства должны быть а) ограниченные б) простые в) универсальные. Иначе в больших проектах программисты просто-напросто перестают понимать друг друга.
Я согласен с вами в том смысле, что богаче и выразительней Лиспа языков нет. Однако же, уверен, что вы все эти цветастые средства не используете в работе. Если вообще работаете с этим языком на дневной работе!
С другой стороны, ваш оппонент, нахваливая гибкость С++ на примере boost замалчивает тот факт, что boost не только не входит в сам язык, но и изрядно усложняет и без того непростую базу. А уродливые макросы… А незабвенные извращения Александреску… И приличные программисты очень, о-о-о-очень, ОЧЕНЬ аккуратно ко всему этому относятся.
В общем, могу сразу обозначить для вас слабые стороны.
1) неприятная работа с большими бинарниками по понятным причинам;
2) пустые директории или файлы в силу архитектуры git невозможны;
3) по первости несколько путает терминология git;
4) роль репозитария несколько уже по сравнению с svn. Если в svn в структуре репозитария запросто можно хранить вообще весь проектный мусор (бинарную документацию pdf или doc, к примеру; исходники сопровождающего проект сайта), то git хотя и позволяет вытаскивать отдельные файлы или директории, но не предназначен для этого. В svn же бранчи — это просто папки, все равно, что хранится.
Из преимуществ.
1) все, что хочется делать с кодом или текстом — в git лучше, быстрее, разнообразнее. Это можно понять и оценить, только поработав; обычно пользователи svn слабо представляют себе разнообразие альтернативных методов работы с хранилищами кода.
2) конечно же, полноценная работа без Инета в силу распределенной природы.
3) вы указали хостинг репозитариев. А вот у меня, к примеру, есть две машины: офисная и домашний ноут. И я запросто делаю синхронизацию кода в любую сторону, без посредников, платных или бесплатных.
Далее мысли в целом по текущему положению дел с системами.
За распределенными репозами образца git — будущее. Это поняли уже все. Даже Фаулер где-то писал про неизбежность постепенного перехода, хотя в первых блог-постах на тему сильно сомневался. Конечно, переход с svn на git, hg, bzк не повысит вашу работоспособность, но определенно упростить жизнь.
Вообще, у концепции ветвления в svn принципиально другой смысл, хранятся они по-другому и используются значительно реже.
Но, признаюсь, жил бы и жил я нормально безо всех этих радостей, если бы не было двух вещей в svn:
1) по проекту разбросан мусор в виде .svn в каждой директории
2) НЕУДОБНО для каждого мелкого личного проекта заводить центральный репоз, потом из него в директорию проекта checkout делать.
А еще в git что очень хорошо, так это удобство настройки файлом .git/config. Переехал с ноутом в другую локальную сеть — достаточно просто сменить адрес условно-центрального репоза — и дальше в работу.
Ну и мелочей всякий масса, типа удобных альясов или конфигурируемости ключевых команд, бла-бла-бла. Это уже для гуру вкусности.
Сейчас же даже на работе уже настроил гейт от git к корпоративному svn и пользуюсь в свое удовольствие.
А как синхронизация происходит..? Между машинами-то? Сервер-то один. На домашней машине, смею предположить.
или в этом и смысл? Чтоб в Сети это дело было доступно..?
Может, есть где код или или что пощупать..?
самопальный комплект комплект скриптов? Вон, тот же git так и организовал: определенная файловая иерархия плюс комплект программок для работы с ней.
Все это — чистые текстовые файлы.