Nemerle.org - Nemerle

...меньше чем за пару дней столько текста наолимпиадить

Рома у нас была (и остается) довольно простая идея — разработать легковесную CMS на базе уже существующего фреймворка под собственные нужды, которые не ограничиваются одним только сайтом для немерла. Это отнюдь не заоблачная цель типа разработки своего веб-сервера, СУБД или чего-то подобного, они вполне достижима и не является неподъемной задачей для местных завсегдатаев. Взамен этого ты предложил:

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

Рома, нам не нужна готовая PHP-CMS, нам не нужна никсовая платформа, нас более чем устраивает билд (в т.ч. и под моно) на винде, мы рады тому функционалу, который оттянул у нас на себя гуглокод и мы не понимаем, зачем нам нужно учиться тратить деньги. Мы хотим иметь блог, статьи в котором будут обладать версионностью, мы хотим иметь вики, интегрированную с билд-сервером хотя бы по части документации, которую мы также хотим обсуждать, мы хотим иметь форумы с функционалом не меньшим чем на RSDN но также с версионностью сообщений и интеграцией с гуглогруппами и местным форумом.

За предложение о помощи — искреннее спасибо, но все, что ты предложил — не решит тех проблем, которые стоят сейчас, либо решит их за счет появления множества других. Посему, я бы предожил закрыть этот глупый спор — в разных ситуациях оба решения могут быть оптимальными для решения поставленной задачи, но в данном конкретном случае, разработка собственного движка оправданна и перспективна. Особенно, если учесть, что она подразумевает практически такой же сбор решения из кубиков, как и твое решение с той только разницей, что наше лежит в программерской плоскости, а твое — в админской. Временные затраты в конечном итоге будет однинаковыми при прочих равных, но твое решение требует существенных изменений в текущей инфраструктуре и делать их только ради того, чтобы из двух равнозначных решений выбрать одно — вряд ли кто-нибудь станет. Просто из соображений экономии собственного времени, которое будет потрачено с гораздо большей (для программиста) пользой при разработке NIH-решения, ибо (как минимум) профильный опыт, в отличии от твоего, т.к. на кой ляд программисту опыт администрирования, мне не смог доказать даже сам Шеридан, поэтому ты тоже не сможешь

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

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

Здравствуйте, Ziaw, Вы писали:

_E_>> Переделать неоригинальный бесплатный дизайн
Z>Для этого нужно найти хороший бесплатный дизайн который допускает переделки и не заставляет делать внизу ссылки — дизайн по сделан из бесплатного темплейта такого-то. Таких нет.
_E_>> Если есть дизайнеры среди community или у кого-то знакомый дизайнер попросить сделать дизайн (маловероятный вариант)
_E_>> Собрать денег и заказать дизайн у фрилансеров
Z>Мне кажется можно попробовать закинуть на дизайнерские форумы клич, возможно кто-то захочет сделать несложный дизайн для довольно посещаемого ресурса. Просто для популярности, ссылку на дизайнера разместить совсем не жалко.
_E_>>Попробовать самим сделать дизайн
Z>Пробуй.

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

Z>А пока я предлагаю обсудить перенос контента в гуглкод.

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

Я также не согласен с тем, что из nemerle.org стоит сделать сайт-визитку. Проекту нужен официальный блог (как минимум, для публикации новостей, как максимум для размещения там информации, не тянущей на статью где-либо), проекту нужен нормальный форум (англоязычный, чтобы уйти от гуглогрупп и русскоязычный, интегрированный с этим форумом), проекту нужна отдельная вики для размещения в ней статей, предназначенных для рядовых пользователей (т.е. программеров, использующих nemerle, но не разрабатывающих его), проекту в конце-концов нужен нормальный билд-сервер и онлайн-REPL. Это, как минимум.

Теперь что касается движка. Я надеялся поднять этот вопрос на волне обсуждения нового дизайна, т.е. чуть позже, но раз уж зашел разговор... Мы с Владом порешили на том, что я организую разработку движка вместе с теми, кто захочет помочь в этом деле. Кое-какие наброски по части дизайна и архитектуры уже есть, но повторюсь, я планировал плотно этим занятся ближе к марту. Конкретно твоя помощь — была бы неоценима, т.к. движок основан на NRails. Соответственно, если есть желание и возможность помочь с этим — общими мазками мы обсуждали то, как это должно выглядеть здесь: Блоки, вики и т.п. и здесь: Re[3]: О будущем RSDN а я тем временем, постараюсь оформить все то, что успел проработать сам и выложу здесь для дальнейшего обсуждения (оперативность правда не обещаю, я до 15-го в отъезде и со временем, честно говоря, не очень).

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

— PEG(вообще пушка — уникальная для нета). Позволяет c легкостью строить генераторы парсеров для разбора сложных синтаксических конструкций.
— компутэйшн-экспрешн(не пробовал еще но думаю скоро попробую). Асинхронность, параллелизм и т.д.
— XML-DSL(он хоть как-то работает?)
— что там еще ?

Сейчас:

Nemerle is a high-level statically-typed programming language for the .NET platform. It offers functional, object-oriented and imperative features. It has a simple C#-like syntax and a powerful meta-programming system

Какой вывод посетитель может сделать из этого абазаца? — еще один экспериментальный язык под точка-нет.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, adontz, Вы писали:

A>Программисты, занимайтесь программированием.

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

P.S: Предупреждая следующий вопрос — нет, крестиком я вышивать не умею

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Можем и можем сделать это достаточно быстро, благодаря тому инструменту, который у нас есть. И поэтому мы именно так и сделаем.

Удачи.

Здравствуйте, Ziaw, Вы писали:

VD>>Надо взяться за него и перестроить. Но для этого не надо трогать старый сайт. Надо сделать новую моруду (альтернативную) и ее потихоничку развивать.

Z>Как раз это я и предложил, ничего лучше гуглкода для альтернативной морды в голову не пришло.

Давай использовать гуглавики для хранения контента и первичного формирования структуры. А далее напишем свою морду под него. Гуглакод будет выступать хранилишем данных (т.е. системой контроля версий). Их формат вики будем считать основным.

Так же надо будет и рсдн-овский формат поддерживать наверно, чтобы не переверстывать стать.

Здравствуйте, Flem1234, Вы писали:

F>Чем дадут тем и будет стрелять, хоть палкой

F>Только, пожалуйста, не Enterprise Library или правку xml конфигов.

=) на самом деле рутина везде нас найдет

F>Хм, и на всякий случай предупреждаю, что в парсинге не силен, так что лучше мне давать что-то несрочное и несложное.
F>Еще и вопросами достану по ходу решения)

парсер уже есть, только я не уверен насчет комментариев. MainParser называется. Макры и синтаксис оно найдет. Насчет комментариев тут подскажут как лучше поступить.

Здравствуйте, Ziaw, Вы писали:

A>>Во-первых, если тебе работодатель платит 10USD в час, то какая разница, подаришь ты проекту час времении или 10USD?
Z>Огромная. Я могу с удовольствием потратить лишний час на хобби и очень редко с удовольствием трачу лишний час на лишние 10$.

Ну я не виноват что у тебя такая унылая работа

На самом деле разницы никакой.

A>>Во-вторых, так тебе специлисты оценят проект и по времени исполнения тоже.
Z>И что мне с того, что я заставлю специалистов оценивать проект? Если оплачивать его никто не собирается?

Это принципиально неправильный подход, делать всё самим. Пусть твоё и его время стоят одинаково. Что лучше, заплатить 100$ специалисту, чтобы он сделал работу за 10 часов или потратить 50 своих часов (500USD), потому что ты не шаришь в вопросе? В итоге всё равно получится хуже. Для меня ответ абсолютно очевиден.

A>>>>А почему ты решил что твоё решение не временное или что на него нужно меньше сил?

Z>>>Мое решение отвечает на вопросы, как развивать и поддерживать. Сил надо тоже много.
A>>На вопросы ты не ответил.
Z>Ответил на оба. Читай внимательно.

Совершенно не ясно почему твоё решение не временное. Где гарантия что завтра NRails не будет объявлена морально устаревшей и тебе захочеться всё переписать на новой библиотеке? Ты ведь не хочешь делать сайт на C#, не так ли? По поводу сил нет и намёка на ответ.

Здравствуйте, VladD2, Вы писали:

A>>А я умею вышиват крестиком, и ещё вяжу. Но я не делаю это для других.
VD>Дык присоеденяйся и сделай сайт для себя.

Могу помочь переехать на Меркуриал и нанести тем самым непоправимую пользу. Я немножеско фанат этой VCS. И могу помочь очень круто настроить Trac. Вам для приличного сайта останется только примитивная CMS и XMLDOC.

Здравствуйте, adontz, Вы писали:

Z>>Я хз, сколько времени сэкономит недокументированное изделие парня из индии, но есть серьезные опасения, что настраивать его можно только правкой исходного кода.

A>Как ты уже заметил, есть альтернативы Sandcastle.

Я даже больше скажу, можно генерировать пустые фиктивные сборки (без кода в методах) для Sandcastle. Если уже у компилятора больше одного врезультата (exe/dll + XML), то можно сделать и три.

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

A>Да, но задача генерации документации от этого никуда не денется. И даже это можно легко решить каким-нибудь <iframe>.

Да все можно решить костылями, только их слишком много получается.

Z>>Ты забыл спросить, нужна ли нам VCS на сайте языка.

A>Не совсем ясно что такое сайт языка, если с него нельзя скачать исходники.

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

A>Не совсем ясно что такое сайт языка, если нельзя отправить баг-репорт.

=) Сколько сайтов посвященных языкам программирования ты видел? http://www.ruby-lang.org/ http://www.python.org/ http://boo.codehaus.org/ Везде внешние системы.

A>Если бы ты не упирался, а взглянул на вещи объективно, ты бы понял что я предлагаю достаточно качественное решение значительно меньшими усилиями.

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

A>Я уже сказал, спуститесь на землю, помогу всё спланировать и настроить. Хотите писать движок сайта, тоже пожалуйста, но я это считаю нерациональной тратой времени.

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

Здравствуйте, Ziaw, Вы писали:

A>>Как ты уже заметил, есть альтернативы Sandcastle.

    http://www.ruby-lang.org/ сайт
http://redmine.ruby-lang.org/ трекер

    http://www.python.org/    сайт
   http://bugs.python.org/    трекер

Не вижу тут никаких внещних систем.

A>>Я уже сказал, спуститесь на землю, помогу всё спланировать и настроить. Хотите писать движок сайта, тоже пожалуйста, но я это считаю нерациональной тратой времени.
Z>Я на земле и прекрасно вижу, что ты не хочешь ничего делать, но желаешь порулить и поучить. Не заморачиваясь хоть какой-то ответственностью за свои решения, будущее языка и сайта тебя абсолютно не трогает.

Прости, но хаму помогать желания нет

Сайт производит очень негативное впечатление. Надо что-то делать, но всем некогда.

Предлагаю перенести важную инфу в гуглкод. Тогда вики смогут править все комитеры, да и интеграция с багтрекером и хранилищем будет неплоха. Еще там можно будет писать по русски тем, кто с английским на Вы, а потом переводить. А на nemerle.org оставить минимальный, приятный на вид, статический сайт-визитку, со ссылками на гуглкод и старый сайт, для археологов. Вобщем, если никто не против, могу этим заняться помаленьку.

Здравствуйте, Ziaw, Вы писали:

Z>Сайт производит очень негативное впечатление. Надо что-то делать, но всем некогда.

Z>Предлагаю перенести важную инфу в гуглкод. Тогда вики смогут править все комитеры, да и интеграция с багтрекером и хранилищем будет неплоха. Еще там можно будет писать по русски тем, кто с английским на Вы, а потом переводить. А на nemerle.org оставить минимальный, приятный на вид, статический сайт-визитку, со ссылками на гуглкод и старый сайт, для археологов. Вобщем, если никто не против, могу этим заняться помаленьку.

Мне кажется, неплохо бы сделать приличный сайт. Вот, например, сайт руби:

http://www.ruby-lang.org/en/

На мой взгляд, выглядит неплохо

Scala тоже ничего:
http://www.scala-lang.org/

Было бы неплохо сделать что-то подобное

Здравствуйте, _Eter_, Вы писали:

_E_>Мне кажется, неплохо бы сделать приличный сайт. Вот, например, сайт руби:

_E_>http://www.ruby-lang.org/en/

_E_>На мой взгляд, выглядит неплохо

_E_>Scala тоже ничего:
_E_>http://www.scala-lang.org/

_E_>Было бы неплохо сделать что-то подобное

Да я уже делал ссылки на кучу языковых сайтов, даже с более простым, но тоже симпатичным дизайном. Сделать нечто подобное никто из тех, кто занимается сейчас немерлом не сможет. Даже если сейчас кто-то даст нам хороший дизайн (нужен очень простой дизайн, но сделать такой простой как в руби может далеко не каждый профессиональный дизайнер), то проблема контента никуда не денется.

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

Здравствуйте, Ziaw, Вы писали:

Z>Да я уже делал ссылки на кучу языковых сайтов, даже с более простым, но тоже симпатичным дизайном. Сделать нечто подобное никто из тех, кто занимается сейчас немерлом не сможет.

А что тут делать? Сайт похожий на сайт руби можно очень легко сделать на какой-нибудь CMS-ке, например на Joomla (я не ней делал несколько сайтов)

Кстати, хорошо бы чтобы сайт был мультиязыковый как, например, сайт ruby

Здравствуйте, _Eter_, Вы писали:

Z>>Да я уже делал ссылки на кучу языковых сайтов, даже с более простым, но тоже симпатичным дизайном. Сделать нечто подобное никто из тех, кто занимается сейчас немерлом не сможет.

_E_>А что тут делать? Сайт похожий на сайт руби можно очень легко сделать на какой-нибудь CMS-ке, например на Joomla (я не ней делал несколько сайтов)

Это кажется.

Здравствуйте, Ziaw, Вы писали:

Z>Это кажется.

Переделать неоригинальный бесплатный дизайн
Если есть дизайнеры среди community или у кого-то знакомый дизайнер попросить сделать дизайн (маловероятный вариант)
Собрать денег и заказать дизайн у фрилансеров
Попробовать самим сделать дизайн

Здравствуйте, _Eter_, Вы писали:

_E_>Здравствуйте, Ziaw, Вы писали:

Z>>Это кажется.

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

_E_> Переделать неоригинальный бесплатный дизайн

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

_E_> Если есть дизайнеры среди community или у кого-то знакомый дизайнер попросить сделать дизайн (маловероятный вариант)
_E_> Собрать денег и заказать дизайн у фрилансеров

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

_E_>Попробовать самим сделать дизайн

Пробуй. А пока я предлагаю обсудить перенос контента в гуглкод.

Здравствуйте, Ziaw, Вы писали:

Z>Сайт производит очень негативное впечатление. Надо что-то делать, но всем некогда.

Z>Предлагаю перенести важную инфу в гуглкод. Тогда вики смогут править все комитеры, да и интеграция с багтрекером и хранилищем будет неплоха. Еще там можно будет писать по русски тем, кто с английским на Вы, а потом переводить. А на nemerle.org оставить минимальный, приятный на вид, статический сайт-визитку, со ссылками на гуглкод и старый сайт, для археологов. Вобщем, если никто не против, могу этим заняться помаленьку.

По поводу сайта: есть идея (использовал в некоторых проектах). В SVN (или в другой системе контроля исходников) хранится содержание сайта в виде XML, а на самом сайте сидит скрипт (использовал PHP) который формирует сайт из SVN. Скрипт берет содержание сайта и CSS из SVN.

Главное достоинство, что для сайта не создаётся отдельное хранилище контента.

Здравствуйте, kochetkov.vladimir, Вы писали:

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

Хорошая новость.

Z>>А пока я предлагаю обсудить перенос контента в гуглкод.

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

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

KV>Я также не согласен с тем, что из nemerle.org стоит сделать сайт-визитку. Проекту нужен официальный блог (как минимум, для публикации новостей, как максимум для размещения там информации, не тянущей на статью где-либо), проекту нужен нормальный форум (англоязычный, чтобы уйти от гуглогрупп и русскоязычный, интегрированный с этим форумом), проекту нужна отдельная вики для размещения в ней статей, предназначенных для рядовых пользователей (т.е. программеров, использующих nemerle, но не разрабатывающих его), проекту в конце-концов нужен нормальный билд-сервер и онлайн-REPL. Это, как минимум.

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

KV>Теперь что касается движка. Я надеялся поднять этот вопрос на волне обсуждения нового дизайна, т.е. чуть позже, но раз уж зашел разговор... Мы с Владом порешили на том, что я организую разработку движка вместе с теми, кто захочет помочь в этом деле. Кое-какие наброски по части дизайна и архитектуры уже есть, но повторюсь, я планировал плотно этим занятся ближе к марту. Конкретно твоя помощь — была бы неоценима, т.к. движок основан на NRails. Соответственно, если есть желание и возможность помочь с этим — общими мазками мы обсуждали то, как это должно выглядеть здесь: Блоки, вики и т.п. и здесь: Re[3]: О будущем RSDN а я тем временем, постараюсь оформить все то, что успел проработать сам и выложу здесь для дальнейшего обсуждения (оперативность правда не обещаю, я до 15-го в отъезде и со временем, честно говоря, не очень).

Я помню эти общие мазки. Новый rsdn выглядит пугающе. Чем смогу помогу конечно, мой логин в скайпе alex_zimin. Со временем тоже не очень, но на рсдн пока есть, значит и на движок найдется

Здравствуйте, Ziaw, Вы писали:

Z>Сайт производит очень негативное впечатление. Надо что-то делать, но всем некогда.

Ну, так возглавь движение и помоги проекту.

Z>Предлагаю перенести важную инфу в гуглкод.

А что даст тупой перенос? К тому же на сайт уже много ссылок есть.
Это все равно что милицию в полицию переименовать.

Z>Тогда вики смогут править все комитеры, да и интеграция с багтрекером и хранилищем будет неплоха.

Может проще дать возможность редатировать сообщения кому угодно? Или заводить эканут автоматом?

Z> Еще там можно будет писать по русски тем, кто с английским на Вы, а потом переводить.

Как показала практика с вики Н2 с переводом в гуглакоде все очень неудобно. Перевод нужно делать только в репозитории (ЮИ это делать не позволяет). Плюс после правки перевода дождаться почти не реально (трудно отслеживать изменения).

Z>А на nemerle.org оставить минимальный, приятный на вид, статический сайт-визитку, со ссылками на гуглкод и старый сайт, для археологов. Вобщем, если никто не против, могу этим заняться помаленьку.

Как я уже скзал — это поломает кучу ссылок.

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

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

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, _Eter_, Вы писали:

_E_>>Мне кажется, неплохо бы сделать приличный сайт. Вот, например, сайт руби:

_E_>>http://www.ruby-lang.org/en/

_E_>>На мой взгляд, выглядит неплохо

_E_>>Scala тоже ничего:
_E_>>http://www.scala-lang.org/

_E_>>Было бы неплохо сделать что-то подобное

Z>Да я уже делал ссылки на кучу языковых сайтов, даже с более простым, но тоже симпатичным дизайном.

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

Z> Сделать нечто подобное никто из тех, кто занимается сейчас немерлом не сможет.

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

Z>Даже если сейчас кто-то даст нам хороший дизайн (нужен очень простой дизайн, но сделать такой простой как в руби может далеко не каждый профессиональный дизайнер), то проблема контента никуда не денется.

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

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

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

За одно будет отличный полигон для твоих Рельсов! В прочем, если брать за основу хранение контента в VCS, то базы данных нам просто не понадобятся. Ну, да по крайней мере залудим ДСЛ-для веба.

Здравствуйте, VladD2, Вы писали:

VD>Надо взяться за него и перестроить. Но для этого не надо трогать старый сайт. Надо сделать новую моруду (альтернативную) и ее потихоничку развивать.

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

Здравствуйте, VladD2, Вы писали:

Для старых ссылок придумали 301 редирект.

... << RSDN@Home 1.2.0 alpha 4 rev. 1111>>

Здравствуйте, VladD2, Вы писали:

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

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

VD>Ну, это ты зря. Просто есть много работы и без этого. Думаю с этим отлично мог бы справиться Кочетков, если бы кто-то согласился бы ему помогать.

Будем считать, что я согласился

Z>>Даже если сейчас кто-то даст нам хороший дизайн (нужен очень простой дизайн, но сделать такой простой как в руби может далеко не каждый профессиональный дизайнер), то проблема контента никуда не денется.

VD>Кочетков более чем может. К тому же можно тупо садрать разделы и размещение элементов сделав только лишь свою графику.

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

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

VD>Я не против, но как раз проблемы то это и не решит. Может лучше тогда уж возродить идею создания движка сайта для немерла на немерле?

Я только за.

VD>За одно будет отличный полигон для твоих Рельсов! В прочем, если брать за основу хранение контента в VCS, то базы данных нам просто не понадобятся. Ну, да по крайней мере залудим ДСЛ-для веба.

База все равно понадобится, все в файлы не загонишь (да и фс в винде тормозит неслабо, форум точно не потянет). У рельс сейчас одна серьезная проблема, это интеграция спарка в студию с поддержкой рельс, кое какую поддержку я в нее впилил, но там C++ и COM в которых я недостаточно соображаю. Вобщем автокомплит и подсветка у меня лично заработали в Exppreimental Hive (спасибо sergee), но перенести на компы других девелоперов без глюков не получилось, в тот момент пришлось плюнуть и редактировать спарк как html.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, Ziaw, Вы писали:

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

Отлично

Здравствуйте, dotneter, Вы писали:

D>Для старых ссылок придумали 301 редирект.

Вот когда он появится и заработает как надо, то можно будет говорить об удалении старого контента. А до тех пор это будет диверсия, а не помощь.

Здравствуйте, Ziaw, Вы писали:

Z>Мои ссылки были на языки, гораздо менее зрелые чем немерл, но имеющие более приличную морду. Дизайн вполне сносный. Рубийный мне тоже понравился больше. А скаловый не понравился вообще.

У Скалы хорошое графическое оформление и приятные менюшки. Но это все мы и сами сделать могли бы. Но вот только не в гугловики.

VD>>Ну, это ты зря. Просто есть много работы и без этого. Думаю с этим отлично мог бы справиться Кочетков, если бы кто-то согласился бы ему помогать.

Z>Будем считать, что я согласился

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

Z>Тупо структуру сайта содрать придется, точнее не содрать, а сделать компиляцию из наиболее удобных сайтов.

+1

Z>А вот красиво "сделать лишь свою графику" — это серьезный труд, я не подозревал, что Владимир этим занимается.

Поверь. У него не плохо получается. Он тут представил дизайн для НСДР и он все очень понравился.

VD>>Я не против, но как раз проблемы то это и не решит. Может лучше тогда уж возродить идею создания движка сайта для немерла на немерле?

Z>Я только за.

ОК. Тогда давай и правда начем со структуризации и перекладки контента в гугловики. А потом прикрутим к этому делу морду.

VD>>За одно будет отличный полигон для твоих Рельсов! В прочем, если брать за основу хранение контента в VCS, то базы данных нам просто не понадобятся. Ну, да по крайней мере залудим ДСЛ-для веба.

Z>База все равно понадобится, все в файлы не загонишь

Не, ну почему же? Очень даже запихнешь. Это же не форумы.

Z>(да и фс в винде тормозит неслабо, форум точно не потянет).

Да ладно наговаривать то. Это не те задачи где эти тормоза будут заметны. РСДН держит по 300 параллельных обращений в секунду и ФС винды ему не мешает.

Z>У рельс сейчас одна серьезная проблема, это интеграция спарка в студию с поддержкой рельс, кое какую поддержку я в нее впилил, но там C++ и COM в которых я недостаточно соображаю.

Я бы вообще отказался бы от спарка. Проще доработать напильником Nemerle.Xml. В нем ожно тупо грузить ХМЛ из файлов и обрабатывать как душа пожелает.

К тому же основная работа для движка сайта будет далеко не в формировании ХТМЛ-я, а в основном в обработке вики-формата, работе с системой хранения версий гугля и т.п. Короче — это будет на 90% код, а не форматирование.

Здравствуйте, Ziaw, Вы писали:

Z>Это кажется.

Здравствуйте, Ziaw, Вы писали:

Я хочу участвовать в проекте, где выдают винтовки?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Я также не согласен с тем, что из nemerle.org стоит сделать сайт-визитку. Проекту нужен официальный блог (как минимум, для публикации новостей, как максимум для размещения там информации, не тянущей на статью где-либо), проекту нужен нормальный форум (англоязычный, чтобы уйти от гуглогрупп и русскоязычный, интегрированный с этим форумом), проекту нужна отдельная вики для размещения в ней статей, предназначенных для рядовых пользователей (т.е. программеров, использующих nemerle, но не разрабатывающих его), проекту в конце-концов нужен нормальный билд-сервер и онлайн-REPL. Это, как минимум.

На счет форумов не уверен. Все же гуглгруппы обеспечиваеют массу сервисов (бэкап, рассылки и т.п.). В остальном, согласен.

Здравствуйте, _Eter_, Вы писали:

KV>>Я также не согласен с тем, что из nemerle.org стоит сделать сайт-визитку. Проекту нужен официальный блог (как минимум, для публикации новостей, как максимум для размещения там информации, не тянущей на статью где-либо), проекту нужен нормальный форум (англоязычный, чтобы уйти от гуглогрупп и русскоязычный, интегрированный с этим форумом), проекту нужна отдельная вики для размещения в ней статей, предназначенных для рядовых пользователей (т.е. программеров, использующих nemerle, но не разрабатывающих его), проекту в конце-концов нужен нормальный билд-сервер и онлайн-REPL. Это, как минимум.

_E_>Мне тоже кажется, что сайт-визитка не подходящее решение.

А в вашем понимании сайт Руби — это сайт-визитка?

Здравствуйте, VladD2, Вы писали:

VD>ОК. Тогда давай и правда начем со структуризации и перекладки контента в гугловики. А потом прикрутим к этому делу морду.

Ok

Z>>База все равно понадобится, все в файлы не загонишь

VD>Не, ну почему же? Очень даже запихнешь. Это же не форумы.

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

Z>>(да и фс в винде тормозит неслабо, форум точно не потянет).

VD>Да ладно наговаривать то. Это не те задачи где эти тормоза будут заметны. РСДН держит по 300 параллельных обращений в секунду и ФС винды ему не мешает.

Сообщения форума лежат в ФС? А тормоза очень заметные, достаточно скопировать хотя бы папку с nemerle в ext4 и NTFS.

Z>>У рельс сейчас одна серьезная проблема, это интеграция спарка в студию с поддержкой рельс, кое какую поддержку я в нее впилил, но там C++ и COM в которых я недостаточно соображаю.

VD>Я бы вообще отказался бы от спарка. Проще доработать напильником Nemerle.Xml. В нем ожно тупо грузить ХМЛ из файлов и обрабатывать как душа пожелает.

Там надо очень много доработать, реализовать полноценный ViewEngine с компиляцией на лету, передачей модели, лейаутами, партиалами. При этом никакого автокомплита в этих XML мы не получим, с тем же успехом можно редактировать спарковские вьюхи как html.

VD>К тому же основная работа для движка сайта будет далеко не в формировании ХТМЛ-я, а в основном в обработке вики-формата, работе с системой хранения версий гугля и т.п. Короче — это будет на 90% код, а не форматирование.

Это только кажется. Хороший гуй он такая штука, малой кровью не делается.

Здравствуйте, Flem1234, Вы писали:

F>Я хочу участвовать в проекте, где выдают винтовки?

А чем бы ты хотел пострелять?

Здравствуйте, Ziaw, Вы писали:

Z>Вики в файлах ляжет неплохо. Я не спорю. Но у сайта обязательно появятся сущности, которые проще хранить в БД. Тот же блог с коментариями, неудобно хранить в фс.

Ну, блог это уже отдельный проект. Кочетков и хотел блогами изначально заняться. Это будут блоги и для Немерле, и для РСДН-а.

Z>Сообщения форума лежат в ФС? А тормоза очень заметные, достаточно скопировать хотя бы папку с nemerle в ext4 и NTFS.

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

Потом причем тут винда? Ты же хочешь использовать гуглевый SCV для хранения вики-страниц. Так он будет тормозить куда круче ФС. Но и тут все просто. Если скорости будет достаточно (по результатам испытаинй), то можно расслабиться и не париться. Если нет, то сделаем кэширование в вайлы с бэкграунд-проверкой изменений и обновлением кэша.

В общем, решать проблемы нужно по мере их поступления. А не то это уже предварительная оптимизация, что как известно причина всех зол.

Z>Там надо очень много доработать, реализовать полноценный ViewEngine с компиляцией на лету, передачей модели, лейаутами, партиалами.

Думаю это не проблема. Данные не плохо формирует твоя Рельса. А уж ViewEngine сделаем и компиляцию на лету тоже.

Лаяуты фигауты делаются на оснвое обычных файлов. Я же тебе говорю, что можно тупо загрузить любой ХМЛ надругаться над ним как хочешь.

Зато мы не будем скованы никаким левым кодом.

Z> При этом никакого автокомплита в этих XML мы не получим,

Это почему это? Добавь схему и будет тебе комплит. Тем более, что это будет расширением схемы HTML-я. А в Nemerle.Xml комплит есть уже сейчас.

Z> с тем же успехом можно редактировать спарковские вьюхи как html.

Дык может и можно. Но зачем? Пойми, свой простой инструмент куда лучше чем чужой сложный.

VD>>К тому же основная работа для движка сайта будет далеко не в формировании ХТМЛ-я, а в основном в обработке вики-формата, работе с системой хранения версий гугля и т.п. Короче — это будет на 90% код, а не форматирование.

Z>Это только кажется. Хороший гуй он такая штука, малой кровью не делается.

Это не кажется. Это так и есть. Гуй гуем, но основная работа будет далеко не в нем. А гуй он ведь в основном ХТМЛ-ем и ЯваСкиптом будет.

Здравствуйте, Ziaw, Вы писали:

F>>Я хочу участвовать в проекте, где выдают винтовки?

Z>А чем бы ты хотел пострелять?

Здравствуйте, VladD2, Вы писали:

VD>В общем, решать проблемы нужно по мере их поступления. А не то это уже предварительная оптимизация, что как известно причина всех зол.

Нет, это называется не будем заранее ограничивать себя файлами, есть куча сценариев, где БД вдруг "неожиданно" понадобится.

VD>Лаяуты фигауты делаются на оснвое обычных файлов. Я же тебе говорю, что можно тупо загрузить любой ХМЛ надругаться над ним как хочешь.

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

VD>Зато мы не будем скованы никаким левым кодом.

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

Z>> При этом никакого автокомплита в этих XML мы не получим,

VD>Это почему это? Добавь схему и будет тебе комплит. Тем более, что это будет расширением схемы HTML-я. А в Nemerle.Xml комплит есть уже сейчас.

Комплит чего? Тегов? Он конечно не помешает, но нужен-то комплит кода. Html редактировать студия и так неплохо умеет.

В свете расширения парсеров, еще раз подниму вопрос. Насколько сложно допилить интеграцию, чтобы она работала в нужных локейшенах ATS сгенерированного не .n файлом. Пусть даже для одного захардкоженного расширения (nxml например). Если это заработает, я готов пилить Nemerle.Xml, получится хороший тул. Если нет — редактировать html в студии будет удобнее чем xml.

Z>> с тем же успехом можно редактировать спарковские вьюхи как html.

VD>Дык может и можно. Но зачем? Пойми, свой простой инструмент куда лучше чем чужой сложный.

VD>>>К тому же основная работа для движка сайта будет далеко не в формировании ХТМЛ-я, а в основном в обработке вики-формата, работе с системой хранения версий гугля и т.п. Короче — это будет на 90% код, а не форматирование.

Зачем лезть в гугл, если его вики хранится в svn? Можно делать регулярный апдейт и брать файлы с локального диска.

Z>>Это только кажется. Хороший гуй он такая штука, малой кровью не делается.

VD>Это не кажется. Это так и есть. Гуй гуем, но основная работа будет далеко не в нем. А гуй он ведь в основном ХТМЛ-ем и ЯваСкиптом будет.

Именно, и хтмл хочется уметь делать максимально просто. Основная работа там как раз несложная, преобразовывать в html лежащие на диске тексты.

Здравствуйте, VladD2, Вы писали:

Z>>А чем бы ты хотел пострелять?

Есть у меня одна винтовка на примете, надо научиться парсить исходники, выдавая по ним доку. Для макросов это имя, синтаксис (если есть, если нет — область применения — метод/класс/выражение) и комментарий перед ними. Формат выдачи пока не важен, главное это все иметь в структурированном виде, с сохранением локейшенов.

VD>Что-то не пойму причем тут сайт?

Дока по языку будет на сайте. В том числе нужна актуальная дока по макрам, а не то, что сейчас лежит не nemerle.org.

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

Здравствуйте, Ziaw, Вы писали:

VD>>В общем, решать проблемы нужно по мере их поступления. А не то это уже предварительная оптимизация, что как известно причина всех зол.

Z>Нет, это называется не будем заранее ограничивать себя файлами, есть куча сценариев, где БД вдруг "неожиданно" понадобится.

Ну, как понадобится, так начнем использовать. Но совать в БД вики я смыла не вижу.
И уж скорость NTFS ни разу не обоснование отказа от файлов. Ее за глаза хватит для наших задач.

VD>>Лаяуты фигауты делаются на оснвое обычных файлов. Я же тебе говорю, что можно тупо загрузить любой ХМЛ надругаться над ним как хочешь.

Z>Ну да, только для удобной работы с ними логики там полно, ты зря считаешь это плевым делом.

Логика логикой, шаблоны шаблонами. Логику конечно надо делать на Nemerle.Xml.

VD>>Зато мы не будем скованы никаким левым кодом.

Z>Да мы и не связаны им особо. Инструмент уже выполняет все задачи, которые xml будет выполнять только после кучи доделок.

Например?

VD>>Это почему это? Добавь схему и будет тебе комплит. Тем более, что это будет расширением схемы HTML-я. А в Nemerle.Xml комплит есть уже сейчас.

Z>Комплит чего? Тегов?

А что в ХМЛ еще что-то есть?

Z>Он конечно не помешает, но нужен-то комплит кода.

А кода в ХМЛ не бывает. Ну, а комлит в Nemerle.Xml и так работает. Плюс в отличии от вшенних ДСЛ-ей есть полноценная диагносрика ошибок и возможность использовать шаблоны как первоклассные сущности.

Z>Html редактировать студия и так неплохо умеет.

Тем более.

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

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

Z> Пусть даже для одного захардкоженного расширения (nxml например).

Для этого надо писать свой LanguageService и регистрировать его вместе с немерловым. В VS 2010 с этим куда как проще. Там все на базе MEF сделано.

Z>Если это заработает, я готов пилить Nemerle.Xml, получится хороший тул. Если нет — редактировать html в студии будет удобнее чем xml.

Да не нужен для Nemerle.Xml свой формат файла. Он и в немерловом коде отлично уляжется.

Еще раз повторюсь. Основной статический HTML можно загружать из отдельных файлов (которые создавать удобным для себя редактором). В этих файлах нужно только помечать области которые надо формировать динамически. Контент для этих областей генерировать при помощи Nemerle.Xml и вставлять в нужные места.

Z>Зачем лезть в гугл, если его вики хранится в svn? Можно делать регулярный апдейт и брать файлы с локального диска.

Я и иемю в виду лезть через svn. Более того лезть может отдельный скрипт, а мы можем собирать данные с винта (локальную копию).

Z>Именно, и хтмл хочется уметь делать максимально просто. Основная работа там как раз несложная, преобразовывать в html лежащие на диске тексты.

Ну, это ты зря. Там нужен интерфейс для реадктирования статей. Интерфйс для срванения версий. Для выделения не переведенных частей документа. Для комита изменений. Это конечно же и ГУЙ в том числею. Но прикладной логики там будет не мало.

А формирвоание ХТМЛ-я это не такая сложная задача при наличии хорошего инструмента. Nemerle.Xml как раз на это заточен. Есть пара идей которые туда можно прилепить. Но это уже по ходу дела.

Здравствуйте, Ziaw, Вы писали:

Z>Дока по языку будет на сайте. В том числе нужна актуальная дока по макрам, а не то, что сейчас лежит не nemerle.org.

Ясно. Хорошая идея! Я планировал в 2.0 сделать для всего описание в коде. Но кое что можно сделать и сейчас.

Z>Конкретно по сайту сейчас делать особо нечего, в первую очередь надо определиться со структурой и наполнением. Не могу же я делегировать эту задачу.

+1

Здравствуйте, VladD2, Вы писали:

VD>Ну, как понадобится, так начнем использовать. Но совать в БД вики я смыла не вижу.
VD>И уж скорость NTFS ни разу не обоснование отказа от файлов. Ее за глаза хватит для наших задач.

Я не отказываюсь от файлов, я просто говорю, что база все равно понадобится.

VD>>>Лаяуты фигауты делаются на оснвое обычных файлов. Я же тебе говорю, что можно тупо загрузить любой ХМЛ надругаться над ним как хочешь.

Z>>Ну да, только для удобной работы с ними логики там полно, ты зря считаешь это плевым делом.

VD>Логика логикой, шаблоны шаблонами. Логику конечно надо делать на Nemerle.Xml.

VD>>>Зато мы не будем скованы никаким левым кодом.

VD>Ну, это ты зря. Там нужен интерфейс для реадктирования статей. Интерфйс для срванения версий. Для выделения не переведенных частей документа. Для комита изменений. Это конечно же и ГУЙ в том числею. Но прикладной логики там будет не мало.

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

VD>А кода в ХМЛ не бывает. Ну, а комлит в Nemerle.Xml и так работает. Плюс в отличии от вшенних ДСЛ-ей есть полноценная диагносрика ошибок и возможность использовать шаблоны как первоклассные сущности.
VD>А формирвоание ХТМЛ-я это не такая сложная задача при наличии хорошего инструмента. Nemerle.Xml как раз на это заточен. Есть пара идей которые туда можно прилепить. Но это уже по ходу дела.

Давай так, есть html:

<html>
<head>
   <title>Список статей</title>
</head>
<body>
  <div id="main">
    <ul>
       <li>Статья 1</li>
       <li>Статья 2</li>
       <li>Статья 3</li>
    </ul>
  </div>
  <div id="sidebar">
     <div class="section">Секция 1</div>
     <div class="section">Секция 2</div>
  </div>
</body>
</html>

То что выделено курсивом и жирным — динамика, остальное шаблон, который Владимир сделал и хочет править в одном файле.
Есть конкретный метод контроллера который был сопоставлен урлу и сформировал данные ["Статья 1", "Статья 2", "Статья 3"] (и, возможно, "Список статей", а может и нет, тогда заголовок должен быть взят откуда-то еще), все остальное должно быть доступно для повторного использования в других контроллерах, экшенах.

Расскажи, что и в каких файлах будет лежать в проекте, по каким правилам твой вьюэнжин соберет все это воедино.

Здравствуйте, Ziaw, Вы писали:

Z>Давай так, есть html:
Z>

Z><html>
Z><head>
Z>   <title>Список статей</title>
Z></head>
Z><body>
Z>  <div id="main">
Z>    <ul>
Z>       <li>Статья 1</li>
Z>       <li>Статья 2</li>
Z>       <li>Статья 3</li>
Z>    </ul>
Z>  </div>
Z>  <div id="sidebar">
Z>     <div class="section">Секция 1</div>
Z>     <div class="section">Секция 2</div>
Z>  </div>
Z></body>
Z></html>
Z>

Z>То что выделено курсивом и жирным — динамика, остальное шаблон, который Владимир сделал и хочет править в одном файле.

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

<html>
<head>
   <title>Список статей</title>
</head>
<body>
  <div id="main">
    <ul id="ArticleList"/>
  </div>
  <div id="Sidebar"/>
</body>
</html>

будет файлом загружаемым динамически.
Если предположить, что код Sidebar и ArticleList будет генерироваться одноименными функциями с приставкой Make, то код будет примерно такой:

def template = LoadXml(path, schima/*гипететическая схема для пущего контроля*/);

template.SetContent("ArticleList", MakeArticleList(...)); 
template.SetContent("Sidebar",     MakeSidebar(...));

Это можно сделать уже сейчас. Все что нужно сделать — это простеньких метод-расширение SetContent().

Если допилить еще один макрос который будет принимать в качестве параметра путь к шаблону, проверять его корректность и генерировать методы для обновления тегов всех тегов формата 'тег id="name"', то код можно представить так (шаблон остается прежним, но он обязан быть доступен при компиляции проекта):

[assembly: DefineHtmlTemptate(name = MyHtmlTemptate, path = "Templates\MyHtmlTemptate.html")]

def template = MyHtmlTemptate.Load(path); // Схема нам не нужна! Но проверка наличия нужных тегов делается!

template.SetArticleList(MakeArticleList(...));
template.SetSidebar(MakeSidebar(...));

path — можно опустить. Тогда шаблон будет браться по старому месту.

Z>Есть конкретный метод контроллера который был сопоставлен урлу и сформировал данные ["Статья 1", "Статья 2", "Статья 3"] (и, возможно, "Список статей", а может и нет, тогда заголовок должен быть взят откуда-то еще), все остальное должно быть доступно для повторного использования в других контроллерах, экшенах.

Ну, вот примерный код контроллера я тебе и продемонстрировал. Что до заголовка, то это дело техники. Главное, что никаких чудес. Все понятно и предсказуемо.

Z>Расскажи, что и в каких файлах будет лежать в проекте, по каким правилам твой вьюэнжин соберет все это воедино.

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

Здравствуйте, VladD2, Вы писали:

VD>Ты почему-то хочешь какой-то магии. Но я не вижу причин для нее. Контроллер пусть берет шаблон, берет данные и впихиваетодно в другое. Ну, а все что нужно автоматизировать, автоматизируем. Главное чтобы все было просто и понятно с первого взгляда.

1. Не должен каждый экшен контроллера обязательно знать о конкретном шаблоне, это лишняя связь, которая добавит гемороя.
2. Не должен каждый экшен контроллера определять место в шаблоне, куда будет вставлен его код. Это дело шаблона, знать куда вставить код контроллера.
3. Не должен каждый экшен контроллера ничего знать про сайдбары, это не его сфера ответственности.

Заметь, ты сейчас из контроллера, который выглядел вот так:

def Articles() : ActionResult
{
  View(db.Articles.Select(a => name).ToList())
}

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

Сделал вот что:

def Articles() : ActionResult
{
  def myData = db.Articles.Select(a => name).ToList();

  def template = MyHtmlTemptate.Load(path); // Схема нам не нужна! Что там проверять в этой схеме? Косяки шаблона браузер в консоли покажет, когда мы будем смотреть страничку.

  template.SetArticleList(MakeArticleList(myData));
  template.SetSidebar(MakeSidebar(sideBar1, sideBar2));
  
  template.ToHtmlResult()
}

В котором захардкожено все, что только можно захардкодить, кроме самого html шаблона. Зря ты думаешь, что в реальности все гораздо сложнее, куча контроллерных методов занимают пару-тройку строк, запрашивая данные у БД, дискового хранилища или еще чего-то. Дублировать в каждом выделенный код — убиться можно. Ну и то, что мы начинаем знать слишком много о представлении данных, играет с нами злую шутку, когда данные надо представлять как-то еще.

Не надо думать, что в MVC придумана какая-то мутная магия с непонятными целями, там все решения имеют свои причины, на которых люди годами набивали себе шишки.

Здравствуйте, Ziaw, Вы писали:

Z>1. Не должен каждый экшен контроллера обязательно знать о конкретном шаблоне, это лишняя связь, которая добавит гемороя.

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

Z>2. Не должен каждый экшен контроллера определять место в шаблоне, куда будет вставлен его код. Это дело шаблона, знать куда вставить код контроллера.

Чудес не бывает. Как-то место идентифицироваться должно. В данном случае оно идентифицируется по значинию тега id, а макра обеспечивает статическую типизацию.

Z>3. Не должен каждый экшен контроллера ничего знать про сайдбары, это не его сфера ответственности.

Опять же твое дело. Шаблоны — это не более чем структура данных загруженная в память. Ее можно загрузить, настроить (добавить нужные данные), а потом клонировать.

Z>Заметь, ты сейчас из контроллера, который выглядел вот так:
Z>

Z>def Articles() : ActionResult
Z>{
Z>  View(db.Articles.Select(a => name).ToList())
Z>}
Z>

Z>т.е. только свое дело, выбирал нужные данные для отображения. Причем нехитрыми внешними манипуляциями мы этот код доводим до возврата джейсона по аяксу, если запрос асинхронный.

Z>Сделал вот что:
Z>

Z>def Articles() : ActionResult
Z>{
Z>  def myData = db.Articles.Select(a => name).ToList();
Z>  def template = MyHtmlTemptate.Load(path); браузер в консоли покажет, когда мы будем смотреть страничку.
Z>  template.SetArticleList(MakeArticleList(myData));
Z>  template.SetSidebar(MakeSidebar(sideBar1, sideBar2));
Z>  template.ToHtmlResult()
Z>}
Z>

Не, не, не. Не надо грязи. То что ты показал в первом примере это решение какой-то другой задачи. В моем варианте код может быть точно таки же. Проблема только в том, что ты перенес весь код во View(). ОК, с точки зрения паттерна MVC это вполне оправданно. Но давай тогда посмотрим на то, что за химия у тебя будет твориться во View()?

У меня это будет:

override View(articles : IEnumerable[string]) : string // или что тут еще может быть?
{
  template.SetArticleList(xml <# <il foreach (name in articles)>$name</> #>);
  template.ToString()
}

А где-то в базовом классе будет установка SetSidebar и загрузка шаблона.

Z>В котором захардкожено все, что только можно захардкодить, кроме самого html шаблона.

Да ладно гнать то

.

Z>Зря ты думаешь, что в реальности все гораздо сложнее, куча контроллерных методов занимают пару-тройку строк, запрашивая данные у БД, дискового хранилища или еще чего-то. Дублировать в каждом выделенный код — убиться можно. Ну и то, что мы начинаем знать слишком много о представлении данных, играет с нами злую шутку, когда данные надо представлять как-то еще.

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

Z>Не надо думать, что в MVC придумана какая-то мутная магия с непонятными целями, там все решения имеют свои причины, на которых люди годами набивали себе шишки.

О, да КО!

ЗЫ

Чудес не бывает. Логика будет там или тут. Ты можешь размазать ее по классам, переместить в шаблон (сделав его программой, а не текстом) и т.п. Но ты получишь все то же решение, если конечно у тебе не возникнет дублирование.

Таким образом определяющими факторами у нас являются:
1. Наличие и объем дублирования.
2. Объем динамических действий (проверок в рантайме).

Решение тем лучше, чем меньше оба пункта.

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

Как я уже тебе не раз говорил при обработки деревьев (а ХТМЛ — это несомненно дерево) рулит рекурсия. Используя Nemerle.Xml можно легко организовать рекурсивный дизайн. Шаблонов при этом может быть сколь угодно много и они могут быть как простым текстом, так и функциями со сколь угодно сложным устройством и тем самым рекурсивным дизайном.

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

Здравствуйте, VladD2, Вы писали:

VD>Это уже твои проблемы, как его пользователя. Сделай интерфейсы и пользуйся ими.

Нет, это проблемы твоего решения, что я должен городить свои интерфейсы, чтобы нормально его использовать.

Z>>2. Не должен каждый экшен контроллера определять место в шаблоне, куда будет вставлен его код. Это дело шаблона, знать куда вставить код контроллера.

VD>Чудес не бывает. Как-то место идентифицироваться должно. В данном случае оно идентифицируется по значинию тега id, а макра обеспечивает статическую типизацию.

Смотри, есть шаблон:

<html>
<head>
   <title>Список статей</title>
</head>
<body>
  <div id="main">
    <use content="view" /> <!-- вот сюда будут вставлены все вьюхи -->
  </div>
  <div id="sidebar">
    <use content="sidebar"> <!-- вот сюда любая вьюха может сгенерить, что угодно, если не сгенерит, будут две секции -->
       <div class="section">Секция 1</div>
       <div class="section">Секция 2</div>
    </use>
  </div>
</body>
</html>

VD>Опять же твое дело. Шаблоны — это не более чем структура данных загруженная в память. Ее можно загрузить, настроить (добавить нужные данные), а потом клонировать.

Грузить в память структуры из сотен объектов на каждый запрос? А потом их еще клонировать? GC не треснет?

VD>Не, не, не. Не надо грязи. То что ты показал в первом примере это решение какой-то другой задачи. В моем варианте код может быть точно таки же. Проблема только в том, что ты перенес весь код во View(). ОК, с точки зрения паттерна MVC это вполне оправданно. Но давай тогда посмотрим на то, что за химия у тебя будет твориться во View()?

VD>У меня это будет:
VD>

VD>override View(articles : IEnumerable[string]) : string // или что тут еще может быть?
VD>{
VD>  template.SetArticleList(xml <# <il foreach (name in articles)>$name</> #>);
VD>  template.ToString()
VD>}
VD>

VD>А где-то в базовом классе будет установка SetSidebar и загрузка шаблона.

А у меня будет:

<ul>
  <li each="article in Model">${article}</li>
</ul>

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

<view content='sidebar'>
   <div class="section">Секция 3</div>
   <div class="section">Секция 4</div>
</view>
<ul>
  <li each="article in Model">${article}</li>
</ul>

Могу вынести этот сайбар в контрол.

<view content='sidebar'>
   <SideBar lst="[3, 4]">
</view>
<ul>
  <li each="article in Model">${article}</li>
</ul>

При этом я правлю только фронтэнд, я не трогаю логику.

Откуда в твоем темплейте появился SetArticleList? ArticleList есть только в одной view, в остальных отображаются свои данные. Что делать, если экшен может рендерить несколько разных вьюх в зависимости от чего угодно?

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

А вот не надо отказываться от контроллеров, ибо эта пара со временем вполне способна постепенно вырасти до нескольких десятков. Да и вообще, лазить в БД из view за данными еще можно, но менять их уже совсем криво.
Они как раз уменьшают сложность, аякс контент, аяск джейсон, xml и простой http запрос возвращают одни и те же данные в разных видах. При отказе, код доставания придется дублировать, либо плодить костыль -однострочный метод.

VD>Чудес не бывает. Логика будет там или тут. Ты можешь размазать ее по классам, переместить в шаблон (сделав его программой, а не текстом) и т.п. Но ты получишь все то же решение, если конечно у тебе не возникнет дублирование.

Все то же решение я не получу по одной простой причине, код будет более связан, придется выдумывать механизмы развязывания (IoC). Придется реализовывать систему подгрузки шаблонов. Еще дофига чего. А плюсов я так и не увидел, кроме заявлений о типизации. Так у меня тоже типизация, прикинь? Зачастую утиная, что рулит в вебе безбожно.

VD>В твоем случае ты размазываешь код по шаблонам и делаешь эти самые шаблоны огромными простынями с огромным количеством дублирования.

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

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

Но пока ты показываешь далеко не компактный, дублирующий, не простой в понимании (все настолько разбросано, что восстановить картину почти нереально), сложный в написании и отладке код.

Здравствуйте, VladD2, Вы писали:

VD>А в вашем понимании сайт Руби — это сайт-визитка?

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

А вообще нужно, наверно, дать понятие сайта визитки. Я спорил насчет сайта-визитки в таком определении:

Z> статический сайт-визитку, со ссылками на гуглкод и старый сайт, для археологов

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Flem1234, Вы писали:

F>>Я хочу участвовать в проекте, где выдают винтовки?

Z>А чем бы ты хотел пострелять?

Только, пожалуйста, не Enterprise Library или правку xml конфигов.
Хм, и на всякий случай предупреждаю, что в парсинге не силен, так что лучше мне давать что-то несрочное и несложное.
Еще и вопросами достану по ходу решения)

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Теперь что касается движка. Я надеялся поднять этот вопрос на волне обсуждения нового дизайна, т.е. чуть позже, но раз уж зашел разговор... Мы с Владом порешили на том, что я организую разработку движка вместе с теми, кто захочет помочь в этом деле. Кое-какие наброски по части дизайна и архитектуры уже есть, но повторюсь, я планировал плотно этим занятся ближе к марту. Конкретно твоя помощь — была бы неоценима, т.к. движок основан на NRails. Соответственно, если есть желание и возможность помочь с этим — общими мазками мы обсуждали то, как это должно выглядеть здесь: Блоки, вики и т.п. и здесь: Re[3]: О будущем RSDN а я тем временем, постараюсь оформить все то, что успел проработать сам и выложу здесь для дальнейшего обсуждения (оперативность правда не обещаю, я до 15-го в отъезде и со временем, честно говоря, не очень).

Владимир, уж простите за мой лексикон, я вас уважаю, но не страдайте хернёй. Если это сайт про Nemerle, то не надо движок сайта тоже делать на Nemerle. Сайты про C++ хостяться на PHP и никто из этого трагедию не делает. Вам шашечки или ехать? Возьмте Друпал или Джумлу и сделайте сайт которым можно пользоваться. Лучше сайт на неправильной технологии, который есть, чем сам на правильной, которого нет.

Здравствуйте, adontz, Вы писали:

A>Владимир, уж простите за мой лексикон, я вас уважаю, но не страдайте хернёй. Если это сайт про Nemerle, то не надо движок сайта тоже делать на Nemerle. Сайты про C++ хостяться на PHP и никто из этого трагедию не делает. Вам шашечки или ехать? Возьмте Друпал или Джумлу и сделайте сайт которым можно пользоваться. Лучше сайт на неправильной технологии, который есть, чем сам на правильной, которого нет.

Роман, уж простите за мой лексикон, но вы явно нихера не пробовали ставить Друпал или Джумлу на винде в продакшине. Джумлу — я пробовал, равно как и медиавики, если уж на то пошло. Эту феерию я еще долго буду помнить, у меня левый глаз потом дергался несколько недель. А заводить под nemerle.org отдельный сервер как-то не вставляет, если честно. Это во-первых. Во-вторых, требования, предъявляемые к сайту nemerle (обязательная интеграция, хотя бы с форумом на RSDN и всей инфраструктурой проекта на гугло коде), означают достаточно глубокое погружение в нутря любой используемой CMS и разработку под нее дополнительных модулей/расширений, либо серьезную правку уже существующих. В случае и джумлы и друпала — это PHP, поэтому увольте. Я на этом языке последний раз писал что-то ощутимо большое около 2 лет назад, и опять этим займусь разве что только под дулом пистолета (да и то, если убить угрожающего не получится). Надеюсь, мое отношение к этому языку я выразил достаточно четко. В разрезе данной задачи, мне представляется более целесообразным (в долгосрочной перспективе) использовать не CMS, а CMF, т.к. повторюсь, только во втором случае будет достаточно пространства для маневров и каких-либо существенных доработок и расширения функционала.

С другой стороны, на Django я реализую необходимый функционал за 2-3 недели в одиночку и в выборе этого фреймворка есть определенный смысл, т.к. его можно закрутить на хостинге GAE и вообще забыть про проблемы с платформой. Эта идея мне нравится намного больше, если бы не одно но:

у нас есть действительно неплохой фреймворк NRails, но нет приложений на нем (в паблике, по крайней мере). Так почему бы не совместить приятное с полезным и наглядно не продемонстрировать мощь языка, реализовав весь необходимый функционал на нем? Тем более, что в любом другом варианте из озвученных выше, мозголожства будет не меньше, а возможно и больше, просто проблемы придется решать не в плоскости функционирования CMS или CMF, а в плоскости ее доработок и интеграции с существующими ресурсами.

Подчеркну — с моей стороны, выбор NRails является достаточно обдуманным и взвешенным, я рассматривал варианты и со сторонними CMS/CMF, учитывая по-возможности все факторы, которые были очевидны на тот момент. И преимуществ от их использования, которые бы перевесили недостатки в данной, конкретной задаче, я не вижу

Здравствуйте, Ziaw, Вы писали:

Z>=) на самом деле рутина везде нас найдет

Без боя не сдамся))

F>>Хм, и на всякий случай предупреждаю, что в парсинге не силен, так что лучше мне давать что-то несрочное и несложное.
F>>Еще и вопросами достану по ходу решения)

Z>парсер уже есть, только я не уверен насчет комментариев. MainParser называется. Макры и синтаксис оно найдет. Насчет комментариев тут подскажут как лучше поступить.

Ок. Попробую на выходных. Если что, буду в форум вопросы постить.

Здравствуйте, Ziaw, Вы писали:

Z>Грузить в память структуры из сотен объектов на каждый запрос? А потом их еще клонировать? GC не треснет?

Не. Для него это не нагрузка. Объекты которые живут не долго стоят очень дешево. К тому же замену можно сделать ленивой, что позволит даже обходиться без загрузки всех данных в память (если это понадобится).

Z>А у меня будет:
Z>

Z><ul>
Z>  <li each="article in Model">${article}</li>
Z></ul>
Z>

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

Z>Все, система выберет лэйаут по умолчанию

Во, во, во "система выберет". На фиг! На фиг выбор который неясно как происходит и неясно где производится. На фиг систему которая требуется для примитивных действий.

Еще раз повторюсь, не надо создавать сложности на ровным месте. Их и так хватит. Код должен быть просто как пробка. Тогда его будет просто расширять и понимать.

Z>(т.е. в подавляющем большинстве вьюх ничего специально писать не надо), лейаут по умолчанию, увидит, что сайдбар не задан и сгенерит сайдбар по умолчанию. Я задаю только то, что нужно. Но если надо, я задам сайдбар так же легко как и ты.

Вот не надо чтобы были какие-то шибко умные сущности которые куда-то сами смотрят и что-то сами делают. Потом кто-то другой придет и будет долго думать кто же подставляет этот долбанный сайдбар? Где же это место в котором надо подправить строчку чтобы добавить ссылку в этом сайдбаре?

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

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

Z>Могу вынести этот сайбар в контрол.

О! Еще одна на фиг не нужная сущность! Вот об этом я и говорю.
Не нужны эти твои "контролы". Есть просто функции (локальные/методы, не суть). На входе параметры, на выходе результат.
Нужно формировать сайдбары с помощью сложной логики? Не вопрос, создаем функцию с параметрами и пусть она их создает.

Z>

Z><view content='sidebar'>
Z>   <SideBar lst="[3, 4]">
Z></view>
Z><ul>
Z>  <li each="article in Model">${article}</li>
Z></ul>
Z>

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

Z>При этом я правлю только фронтэнд, я не трогаю логику.

Ты размазываешь логику по шаблонам. Все эти "<SideBar lst="[3, 4]">", "<li each="article in Model">${article}</li>" — это код засунутый внутрь шаблонов контента.

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

Z>Откуда в твоем темплейте появился SetArticleList? ArticleList есть только в одной view, в остальных отображаются свои данные. Что делать, если экшен может рендерить несколько разных вьюх в зависимости от чего угодно?

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

Z>А вот не надо отказываться от контроллеров, ибо эта пара со временем вполне способна постепенно вырасти до нескольких десятков.

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

Научись смотреть на дизайн кода не шаблонно. Код должен быт хорошим! Это все что от него требуется. А то как этого достичь уже зависит от тебя и ситуации. Если бездумно использовать шаблоны проектирования, то рано или поздно код превратится в задницу.

Z> Да и вообще, лазить в БД из view за данными еще можно, но менять их уже совсем криво.

Все зависит от объема кода и сложности задачи. Возможно, что операция что ты делаешь вообще будет стандратная и ее просто надо вынести в функцию. А раз мы просто вызываем одну функцию, то что нам даст контроллер? Лишний файл?

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

Z>Они как раз уменьшают сложность, аякс контент, аяск джейсон, xml и простой http запрос возвращают одни и те же данные в разных видах. При отказе, код доставания придется дублировать, либо плодить костыль -однострочный метод.

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

VD>>Чудес не бывает. Логика будет там или тут. Ты можешь размазать ее по классам, переместить в шаблон (сделав его программой, а не текстом) и т.п. Но ты получишь все то же решение, если конечно у тебе не возникнет дублирование.

Z>Все то же решение я не получу по одной простой причине, код будет более связан, придется выдумывать механизмы развязывания (IoC).

Знаешь, я бы пионером IoC и других финтефлюшек. Еще когда об этом на Руси никто не слышал я старался впихнуть в наши журналы статьи об IoC и других Спрингах. Но когда я познакомился и освоил Немерл, то почему-то я вообще перестал думать об IoC. Более того когда я сейчас вижу применение IoC, то очень часто меня это коробит, так как я вижу другие, более простые пути достичь того же самого.

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

Я думаю, что прототип у нас не займет много времени. Ну, а далее сделаем пару тестовых страниц и оценим, что получилось.

Z> Придется реализовывать систему подгрузки шаблонов.

Это элементарно.

Z>Еще дофига чего. А плюсов я так и не увидел, кроме заявлений о типизации. Так у меня тоже типизация, прикинь? Зачастую утиная, что рулит в вебе безбожно.

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

Я почему-то уверен, что полученное решение будет проще, быстрее и гибче. И при этом мы еще избавимся от лишней зависимости, получим интеллисенс, и возможность наращивать интеллектуальность нашего движка (код же будет целиком наш!).

VD>>В твоем случае ты размазываешь код по шаблонам и делаешь эти самые шаблоны огромными простынями с огромным количеством дублирования.

Z>Ты делаешь очень смелые предположения о моих шаблонах.

Возможно. Ну, что попробуем?

Здравствуйте, _Eter_, Вы писали:

_E_>В моем понимании сайт руби, что-то промежуточное между визиткой и порталом, по крайней мере его можно расширить недостающей функциональностью.

Вот и я думал о чем-то таком. Просто страничка с рекламой мне не нравится.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Роман, уж простите за мой лексикон, но вы явно нихера не пробовали ставить Друпал или Джумлу на винде в продакшине.

Я не только не пробовал, мне и голову не приходило. VDS стоит 20USD, shared и того меньше. Моё время явно больше.

Здравствуйте, Ziaw, Вы писали:

Z>Аналогия некорректна. Никто не пишет CMS на С++ не потому, что есть PHP, а потому, что язык не предназначен для этого. Nemerle подходит для веб разработки совершено не хуже C#, это обычный dogfooding.

ИМХО и C# не особо-то предназначен, ну да ладно.

Z>Что касается NRails, он ничего не навязывает кроме блтулкита, который и так бы использовался и спарка, который, за неимением поддержки razor является наиболее удобным view engine на текущий момент.

Количество сил ограничено. Люди работают бесплатно. Лучше сконцентрироваться на одно задаче и сделать её хорошо, чем писать компилятор, IDE, MVC-фреймворк для сайтов, сам сайт и ещё бог знает что.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Роман, уж простите за мой лексикон, но вы явно нихера не пробовали ставить Друпал или Джумлу на винде в продакшине.
A>Я не только не пробовал, мне и голову не приходило. VDS стоит 20USD, shared и того меньше. Моё время явно больше.

Угу. Как на никсовом VDS будем делать билд-сервер?

Здравствуйте, VladD2, Вы писали:

Z>>А у меня будет:
Z>>

Z>><ul>
Z>>  <li each="article in Model">${article}</li>
Z>></ul>
Z>>

VD>Этот код будет внутри того что у меня было бы шаблоном. Т.е. нарушение правил разделения дизайна и контента.

Где ты тут увидел дизайн? Это чистый контент. Это представление контента в виде списка, никакого дизайна. А вот дизайн уже этому списку назначит роль, это может быть выпадающее выпадающее меню или табы.

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

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

Z>>Все, система выберет лэйаут по умолчанию

VD>Во, во, во "система выберет". На фиг! На фиг выбор который неясно как происходит и неясно где производится. На фиг систему которая требуется для примитивных действий.

Что конкретно тебе не ясно? У сайта есть дефолтный лэайут, лежит в "Views/Layouts/Application.spark". Это то, куда я могу засунуть дизайн от Кочеткова и обойтись косметическими правками всего остального сайта.

VD>Еще раз повторюсь, не надо создавать сложности на ровным месте. Их и так хватит. Код должен быть просто как пробка. Тогда его будет просто расширять и понимать.

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

VD>Вот не надо чтобы были какие-то шибко умные сущности которые куда-то сами смотрят и что-то сами делают. Потом кто-то другой придет и будет долго думать кто же подставляет этот долбанный сайдбар? Где же это место в котором надо подправить строчку чтобы добавить ссылку в этом сайдбаре?

Не надо тут думать, надо пойти в лейаут и посмотреть, кто отвечает за рендер сайдбара.

VD>Все должно быть очень просто. У нас есть базовый шаблон. Мы можем поместить какое-то начальное значение сайтбара в него. Если для ряда страниц нам нужно изменить сайтбар, то мы тупо вводим для них базовый класс и в его конструкторе (или каком-то методе) клонируем шаблон и меняем в нем сайтбар (клонирование можно автоматизировать). Все страницы (представления) унаследованные от данного класса будут работать уже с измененным шаблоном.

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

VD>Получается простая логика которая не удивляет программиста и при этом обеспечивает очень компактный и хорошо поддерживаемый код.

Давай код, сравним простоту. Только весь код, все файлы, я тебе привел уже все файлы, некоторые даже в нескольких сценариях.

Z>>Могу вынести этот сайбар в контрол.

VD>О! Еще одна на фиг не нужная сущность! Вот об этом я и говорю.
VD>Не нужны эти твои "контролы". Есть просто функции (локальные/методы, не суть). На входе параметры, на выходе результат.
VD>Нужно формировать сайдбары с помощью сложной логики? Не вопрос, создаем функцию с параметрами и пусть она их создает.

Чем контрол отличается от функции с параметрами?

VD>И что мы имеем? Куча выдуманных сущностей которые вообще не нужны и при этом смешение шаблона и кода. Код вуалируется под теги, сплайсы и т.п.
VD>А ради чего все это? А ради безумного стремления иметь один файл с перемешанным в нем кодом и контентом.

Безумное оно только в твоем понимании.

VD>Ты размазываешь логику по шаблонам. Все эти "<SideBar lst="[3, 4]">", "<li each="article in Model">${article}</li>" — это код засунутый внутрь шаблонов контента.

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

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

Что конкретно я не могу? Все мои сущности нужные.

Z>>Откуда в твоем темплейте появился SetArticleList? ArticleList есть только в одной view, в остальных отображаются свои данные. Что делать, если экшен может рендерить несколько разных вьюх в зависимости от чего угодно?

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

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

VD>Научись смотреть на дизайн кода не шаблонно. Код должен быт хорошим! Это все что от него требуется. А то как этого достичь уже зависит от тебя и ситуации. Если бездумно использовать шаблоны проектирования, то рано или поздно код превратится в задницу.

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

Z>> Да и вообще, лазить в БД из view за данными еще можно, но менять их уже совсем криво.

VD>Все зависит от объема кода и сложности задачи. Возможно, что операция что ты делаешь вообще будет стандратная и ее просто надо вынести в функцию. А раз мы просто вызываем одну функцию, то что нам даст контроллер? Лишний файл?

Влад, ты в предмете разберись. Мы всегда вызываем контроллер. Если ему надо рендерить что-то сложное, у тебя будет темплейт и у меня будет темплейт. Не надо — ну и не надо.

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

Во! Именно ты ее и хочешь размазать. У меня все разделено, контроллер достал данные, отображение их их отобразило. А твои рассуждения про то, что все надо просто распихать по фукнциям и будет зашибись — гроша ломаного не стоят без реальных примеров. Пусть даже для игрушечных респонсов, пример которого я привел.

VD>>>Чудес не бывает. Логика будет там или тут. Ты можешь размазать ее по классам, переместить в шаблон (сделав его программой, а не текстом) и т.п. Но ты получишь все то же решение, если конечно у тебе не возникнет дублирование.

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

VD>Я думаю, что прототип у нас не займет много времени. Ну, а далее сделаем пару тестовых страниц и оценим, что получилось.

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

VD>У тебя движок рендеренга который создает ряд проблем и не предоставляет в замен существенного упрощения разработки. Я конечно же могу ошибаться, но потому я предлагаю смастерить прототип и попробовать все в деле.

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

VD>Возможно. Ну, что попробуем?

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

Здравствуйте, adontz, Вы писали:

Z>>Аналогия некорректна. Никто не пишет CMS на С++ не потому, что есть PHP, а потому, что язык не предназначен для этого. Nemerle подходит для веб разработки совершено не хуже C#, это обычный dogfooding.

A>ИМХО и C# не особо-то предназначен, ну да ладно.

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

A>Количество сил ограничено. Люди работают бесплатно. Лучше сконцентрироваться на одно задаче и сделать её хорошо, чем писать компилятор, IDE, MVC-фреймворк для сайтов, сам сайт и ещё бог знает что.

Что ты предлагаешь-то? MVC фреймоврк уже есть, его не надо особо писать. Сайт в таком виде оставлять нельзя, это же кошмар полный. Из него и складывается впечатление о проекте. Надо релизить немерл и пиарить его, а пиарить сейчас тупо вредно, такой сайт закроет сразу 80% посещающих. Остальные не будут пробовать язык, до того как почитают о нем, а столкнувшись с тем, что половина ссылок битая, половину найти сложно и вообще непонятно что тут читать уйдут остальные 20%. Потому и получается, что язык юзают только те, кому уши о нем прожужжали и они пересилили себя.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>Роман, уж простите за мой лексикон, но вы явно нихера не пробовали ставить Друпал или Джумлу на винде в продакшине.
A>>Я не только не пробовал, мне и голову не приходило. VDS стоит 20USD, shared и того меньше. Моё время явно больше.
KV>Угу. Как на никсовом VDS будем делать билд-сервер?

А почему всё должно быть на одном сервере?

Что за мания такая.

Здравствуйте, Ziaw, Вы писали:

Z>Что ты предлагаешь-то?

Взять готовую CMS и получить гарантированный результат за разумное время с минимальными усилиями.

Z>MVC фреймоврк уже есть, его не надо особо писать.

Фреймворк есть в виде какой-то первой версии. Его надо будет обкатывать и доделывать. ASP.NET MVC не с певрого раза получился, аж три версии. Почему у вас должно быть лучше? Потом, фреймворк — не сайт, сайт писать таки надо. Да, я понимаю, Немерле есть великая экономия сил, но всё же надо смотреть на это с точки зрения руководителя проекта, а не программиста-энтузиаста. Надо разделить задачи на важные и второстепенные и решать их в соответсвии с приоритетами. Важно ли чтобы сайт был красивым? Да! Важно ли чтобы он был на Немерле? Нет!

Z>Сайт в таком виде оставлять нельзя, это же кошмар полный. Из него и складывается впечатление о проекте. Надо релизить немерл и пиарить его, а пиарить сейчас тупо вредно, такой сайт закроет сразу 80% посещающих.

Да, сайт — говно. Я с этим и не спорю. Но это вопрос дизайна и только дизайна. К движку или языку на котором написан движок он отношения не имеет. Если это так уж волнует, скиньтесь и на каком-нибудь free-lance.ru вам баксов за 200-300 сделают замечательный дизайн. Мне всю символику (логотип, наклейки на автомобили, сайт, майки) нарисовали не так давно за 500. Программисты, занимайтесь программированием.

Здравствуйте, adontz, Вы писали:

A>Взять готовую CMS и получить гарантированный результат за разумное время с минимальными усилиями.

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

A>Фреймворк есть в виде какой-то первой версии. Его надо будет обкатывать и доделывать. ASP.NET MVC не с певрого раза получился, аж три версии. Почему у вас должно быть лучше?

Ну это же не фреймворк с нуля, это хелперы к MVC.

A>Потом, фреймворк — не сайт, сайт писать таки надо. Да, я понимаю, Немерле есть великая экономия сил, но всё же надо смотреть на это с точки зрения руководителя проекта, а не программиста-энтузиаста. Надо разделить задачи на важные и второстепенные и решать их в соответсвии с приоритетами. Важно ли чтобы сайт был красивым? Да! Важно ли чтобы он был на Немерле? Нет!

Писать все равно придется. Ты пойми, что CMS даст тут ровно ничего. Дизайн придется превращать в шаблон для этой CMS, бороться с ее собственным дизайном и т.д. Готовые компоненты которые можно взять это вики и блог. Только и то и другое придется допиливать. Блог делается за полдня-день, мирор гугловой вики на файлах — чуть дольше. Допиливание займет больше, это точно

Z>>Сайт в таком виде оставлять нельзя, это же кошмар полный. Из него и складывается впечатление о проекте. Надо релизить немерл и пиарить его, а пиарить сейчас тупо вредно, такой сайт закроет сразу 80% посещающих.

A>Да, сайт — говно. Я с этим и не спорю. Но это вопрос дизайна и только дизайна. К движку или языку на котором написан движок он отношения не имеет. Если это так уж волнует, скиньтесь и на каком-нибудь free-lance.ru вам баксов за 200-300 сделают замечательный дизайн. Мне всю символику (логотип, наклейки на автомобили, сайт, майки) нарисовали не так давно за 500. Программисты, занимайтесь программированием.

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

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

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>>Роман, уж простите за мой лексикон, но вы явно нихера не пробовали ставить Друпал или Джумлу на винде в продакшине.
A>>>Я не только не пробовал, мне и голову не приходило. VDS стоит 20USD, shared и того меньше. Моё время явно больше.
KV>>Угу. Как на никсовом VDS будем делать билд-сервер?

A>А почему всё должно быть на одном сервере?

Что за мания такая.

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

Напомню, что RSDN (как движок) появился на свет именно из-за того, что его создателей не устраивали имеющиеся на тот момент движки форумов. В каком месте бы сейчас он был, возьми они что-то готовое — хз. В этом движке также заинтересован IT, он нужен ему для булкита, кроме того, Игорь обещал помочь с архитектурой и осуществлять методическую помощь, так сказать. В конечном итоге, подобный движок мог бы стать и альтернативным онлайн-клиентом для RSDN. Так почему бы и нет?

Здравствуйте, Ziaw, Вы писали:

Z>Я помню эти общие мазки. Новый rsdn выглядит пугающе.

почему, если не секрет?

Z>Чем смогу помогу конечно,

Я не был в курсе того, что ты "отдаешь в хорошие руки" NRails, в смысле — не имеешь возможности заниматься им. Я как-то пропустил этот момент осенью. Это по прежнему так, или что-то поменялось?

Z>мой логин в скайпе alex_zimin.

Мой vladmir.v.kochetkov, но я там в плане голоса смогу быть только по своему возвращению

Z>Со временем тоже не очень, но на рсдн пока есть, значит и на движок найдется

Ок, супер, спасиб

Есть ли в NRails какие-либо нерешенные задачи/проблемы, нереализованный функционал и прочие вопросы, которые бы стоило закрыть до того, как начать работать над движком?

Здравствуйте, Ziaw, Вы писали:

Z>Я помню эти общие мазки. Новый rsdn выглядит пугающе.

Z>Со временем тоже не очень, но на рсдн пока есть, значит и на движок найдется

Ок, супер, спасиб

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>

почему, если не секрет?

объемом замысла

KV>Я не был в курсе того, что ты "отдаешь в хорошие руки" NRails, в смысле — не имеешь возможности заниматься им. Я как-то пропустил этот момент осенью. Это по прежнему так, или что-то поменялось?

Тогда у меня кончился вебпроект в котором я юзал рельсы и начались не веб

Было не очень понятно, что делать с фреймворком дальше. Выдумывать фичи просто так, не хотелось, писать свою версию интеграции для спарка тоже. Стал актуален 3й MVC, но на 4м фреймворке. Я решил сделать паузу до второй версии немерла для избавления от проблем с интеграцией и перехода на 3 MVC.

KV>Мой vladmir.v.kochetkov, но я там в плане голоса смогу быть только по своему возвращению

Я обычно без микрофона, просто чат зачастую удобнее форума.

KV>Ок, супер, спасиб

Есть ли в NRails какие-либо нерешенные задачи/проблемы, нереализованный функционал и прочие вопросы, которые бы стоило закрыть до того, как начать работать над движком?

Одну я уже назвал, в спарковских вьюхах нет интелисенса. Мне удалось заставить его заработать, https://github.com/Ziaw/spark, но для нормальной инсталляции аддина, требуется его подписать. А подпись майкрософта мне так и не удалось получить тогда, было похоже на то, что их вообще перестали выдавать. Еще одна проблема там — в инсталяцию пришлось включить сами рельсы, так что вьюха компилируется для интелисненса версией рельс, отличной от текущей. Надо бы перейти на позднее связывание, но я чето утонул там в дизайне интеграции.

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

Здравствуйте, Ziaw, Вы писали:

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

Тем не менее, больиснтво сайтов, в том числе много сложных, на готовых движках.

Z>Писать все равно придется. Ты пойми, что CMS даст тут ровно ничего. Дизайн придется превращать в шаблон для этой CMS, бороться с ее собственным дизайном и т.д. Готовые компоненты которые можно взять это вики и блог. Только и то и другое придется допиливать. Блог делается за полдня-день, мирор гугловой вики на файлах — чуть дольше. Допиливание займет больше, это точно

Нормальный блог не делает за пол дня. За пол-дня делается простыня сообщений.

Z>Далеко не только дизайн. Да и совсем несложный там сайт получается. Все что сложное (приведение доки в порядок, создание автогенератора док) делать придется все равно.

Эти задачи к сайту отношения не имеют.

Z>Ты посмотри на сайты других языков, почти все пришли к тем же выводам.

Вот именно что пришли. Я не думаю что первый сайт о Питоне был написан на Питоне. Руби, прости, но фанатики какие-то, они даже свой нарошный веб-сервер написали. Будете писать свой веб-сервер?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>P.S: Предупреждая следующий вопрос — нет, крестиком я вышивать не умею

А я умею вышиват крестиком, и ещё вяжу. Но я не делаю это для других.

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Потому что админить их придется мне, хотя бы.

Я сейчас админю development environment на линуксовском VDS. Сам. До того админил сам на Windows. Я не админ, просто нанимать было некого (софт сильно специфический) и было время разобраться самому. Учитывая, что к моменту перезда я только-только выучил команду cp, мне Линуксовский сервер админить явно проще.

KV>И обеспечивать взаимодействие между VDS, гуглокодом и RSDN4 — тоже.

Гуглокод вам вообще не нужен. VCS поставите в том же VDS, напишете пару хуков чтобы билд-сервер дёргать и всё. Кстати, билд сервер под моно можно поставить на соседней VDS.

KV>А, учитывая, что контингент участников проекта Nemerle не пестрит никсовыми админами и программерами на динамике, встает также вопрос о том, кто будет все это дорабатывать и развивать?

Для этого не нужно больших сил. Исходный код хуков на все случаи жизни ищется в интернете. Время занимает их адаптация под Windows.

KV>Мы обсуждали с Владом вариант с переносом сайта с сервера поляков на VDS непосредственно перед переносом, но пришли к мнению, что целесообразнее держать все на одном сервере. По причинам, которые я уже озвучил.

Тем не менее у меня был один сервер для всего и я понял какая это лажа. Разделил и стало легче жить. Даже с учётов моей линуксотупости, админить изначально линуксовский софт под Линуксом заметно проще.

KV>Напомню, что RSDN (как движок) появился на свет именно из-за того, что его создателей не устраивали имеющиеся на тот момент движки форумов. В каком месте бы сейчас он был, возьми они что-то готовое — хз. В этом движке также заинтересован IT, он нужен ему для булкита, кроме того, Игорь обещал помочь с архитектурой и осуществлять методическую помощь, так сказать. В конечном итоге, подобный движок мог бы стать и альтернативным онлайн-клиентом для RSDN. Так почему бы и нет?

Да, идея классная. Я не говорю что идея плохая. Меня волнует, а не надорвётесь ли?

P.S. Я могу вам всё это настроить, но покупать linode не буду, потому что не хочу владеть активами связанными с Nemerle.

Здравствуйте, adontz, Вы писали:

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

A>Тем не менее, больиснтво сайтов, в том числе много сложных, на готовых движках.

Примеры в студию. Большинство сайтов вообще не сайты а странички в ЖЖ.

Z>>Писать все равно придется. Ты пойми, что CMS даст тут ровно ничего. Дизайн придется превращать в шаблон для этой CMS, бороться с ее собственным дизайном и т.д. Готовые компоненты которые можно взять это вики и блог. Только и то и другое придется допиливать. Блог делается за полдня-день, мирор гугловой вики на файлах — чуть дольше. Допиливание займет больше, это точно

A>Нормальный блог не делает за пол дня. За пол-дня делается простыня сообщений.

Простыня сообщений, с катом, комментариями, аттачем картинок граватарами, rss и редактором (по крайней мере на ror я такое делал, здесь будет чуть дольше, потому то нет готовых acts_as_threaded_comments).

Да, не будет нормального поиска по блогу, архивов но для начала хватит.

Z>>Далеко не только дизайн. Да и совсем несложный там сайт получается. Все что сложное (приведение доки в порядок, создание автогенератора док) делать придется все равно.

A>Эти задачи к сайту отношения не имеют.

A>Вот именно что пришли. Я не думаю что первый сайт о Питоне был написан на Питоне.

Первый сайт для немерла тоже на php, но его явно уже не хватает.

A>Руби, прости, но фанатики какие-то, они даже свой нарошный веб-сервер написали. Будете писать свой веб-сервер?

Сервер писали для рельс. Я кстати тоже подумываю, только во втором немерле. Хотя может найду другой способ добиться компиляции на лету.

Здравствуйте, Ziaw, Вы писали:

A>>Тем не менее, больиснтво сайтов, в том числе много сложных, на готовых движках.

Z>Примеры в студию. Большинство сайтов вообще не сайты а странички в ЖЖ.

http://community.joomla.org/showcase/

A>>Нормальный блог не делает за пол дня. За пол-дня делается простыня сообщений.
Z>Простыня сообщений, с катом, комментариями, аттачем картинок граватарами, rss и редактором (по крайней мере на ror я такое делал, здесь будет чуть дольше, потому то нет готовых acts_as_threaded_comments).

Будем откровенны, что ты как тимлид сделаешь, если тебе программист скажет, что что-то будет "чуть дольше"?

Z>Да, не будет нормального поиска по блогу, архивов но для начала хватит.

А подсветка синтаксиса? А в комментариях? А кат в комментариях для блоков кода? А чтобы из-за отступов вёрстка не разъезжлась, как это бывает в ЖЖ? А теги будут? А автодополнение при заполнении тегов? А потом захочется чтобы блог был не один, а несколько: блок PEG, блог компилятора, блок NRails с разными группами авторов. А антиспам? А баны?

A>>Вот именно что пришли. Я не думаю что первый сайт о Питоне был написан на Питоне.
Z>Первый сайт для немерла тоже на php, но его явно уже не хватает.

То что есть сейчас вообще не сайт. Это только вики-движок.

A>>Руби, прости, но фанатики какие-то, они даже свой нарошный веб-сервер написали. Будете писать свой веб-сервер?

Z>Сервер писали для рельс. Я кстати тоже подумываю, только во втором немерле. Хотя может найду другой способ добиться компиляции на лету.

Надо всё же программистов иногда заставлять администрировать то, что они пишут.

Здравствуйте, adontz, Вы писали:

A>>>Тем не менее, больиснтво сайтов, в том числе много сложных, на готовых движках.

Z>>Примеры в студию. Большинство сайтов вообще не сайты а странички в ЖЖ.
A>http://community.joomla.org/showcase/

Ты думаешь, что сложные сайты берут и ставят джумлу, на самом деле они берут и разрабатывают сайт на джумле. Никто из присутствующих не желает изучать кишки готовой CMS. А лезть в них придется рано или поздно (причем первые wtf начнутся еще на этапе создания шаблона из готового дизайна).

Насчет заказать: люди тут собрались, в основном потому, что им нравится писать на nemerle, а не для того, чтобы сэкономить свое время за счет своих денег.

A>>>Нормальный блог не делает за пол дня. За пол-дня делается простыня сообщений.
Z>>Простыня сообщений, с катом, комментариями, аттачем картинок граватарами, rss и редактором (по крайней мере на ror я такое делал, здесь будет чуть дольше, потому то нет готовых acts_as_threaded_comments).
A>Будем откровенны, что ты как тимлид сделаешь, если тебе программист скажет, что что-то будет "чуть дольше"?

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

A>А подсветка синтаксиса? А в комментариях? А кат в комментариях для блоков кода? А чтобы из-за отступов вёрстка не разъезжлась, как это бывает в ЖЖ? А теги будут? А автодополнение при заполнении тегов? А потом захочется чтобы блог был не один, а несколько: блок PEG, блог компилятора, блок NRails с разными группами авторов. А антиспам? А баны?

Подсветка синтаксиса и кат будут в рамках викиразметки. Ее кстати придется прикручивать к CMS точно так же. Причем писать парсер на js или php имея готовый парсер языка. Либо париться с интеграцией кода на немерле и php. Антиспам и теги (без облака, просто как разделы) это еще пол дня. Насчет всего остального: а) когда понадобится тогда и надо делать б) доделывать пхпшный движок никто бесплатно не будет.

A>То что есть сейчас вообще не сайт. Это только вики-движок.

То, что ты предлагаешь это тоже не сайт, это cms-движок. На медиавики тоже делают неплохие сайты.

A>>>Руби, прости, но фанатики какие-то, они даже свой нарошный веб-сервер написали. Будете писать свой веб-сервер?

Z>>Сервер писали для рельс. Я кстати тоже подумываю, только во втором немерле. Хотя может найду другой способ добиться компиляции на лету.

A>

Надо всё же программистов иногда заставлять администрировать то, что они пишут.

Если ты про мою задумку, так ее администрировать не надо, она для разработки и отладки. Если про руби: не испытываю никаких проблем с администрированием связки passenger+nginx. То, что оно специально заточено под рельсы дает много приятных плюшек.

Здравствуйте, Ziaw, Вы писали:

Z>Ты думаешь, что сложные сайты берут и ставят джумлу, на самом деле они берут и разрабатывают сайт на джумле. Никто из присутствующих не желает изучать кишки готовой CMS. А лезть в них придется рано или поздно (причем первые wtf начнутся еще на этапе создания шаблона из готового дизайна).

То что всё дело в Фатальном недостатке я и не сомневался.

Z>Насчет заказать: люди тут собрались, в основном потому, что им нравится писать на nemerle, а не для того, чтобы сэкономить свое время за счет своих денег.

Чтобы писать на Немерле красивый сайт не нужен. Думаю цели всё же несколько другие.

A>>Будем откровенны, что ты как тимлид сделаешь, если тебе программист скажет, что что-то будет "чуть дольше"?
Z>Спрошу крайний срок. Но тут никто не может ставить крайних сроков. Вариантов немного, либо находятся люди желающие дорабатывать CMS, либо мы с Кочетковым пишем сайт.

И в каком варианте риски выше?

Z>Подсветка синтаксиса и кат будут в рамках викиразметки. Ее кстати придется прикручивать к CMS точно так же. Причем писать парсер на js или php имея готовый парсер языка.

Вообще-то есть куча готовых средств именно для подсветки синтакисиса. Писать ничего не надо.

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

Большинство задач решаться установкой плагинов

Надо всё же программистов иногда заставлять администрировать то, что они пишут.
Z>Если ты про мою задумку, так ее администрировать не надо, она для разработки и отладки. Если про руби: не испытываю никаких проблем с администрированием связки passenger+nginx. То, что оно специально заточено под рельсы дает много приятных плюшек.

Да вот я бы не сказал, что WSGI сильно мешает писать на Питоне

Здравствуйте, adontz, Вы писали:

A>Большинство задач решаться установкой плагинов

Давай всё же утоним, что дело не в том, что на Немерле всё будет лучше, а в том, что ты не умеешь разрабатывать сайты на готовых CMS и тебе кажется что написать всё с нуля на Немерле это быстрее, чем изучить гтовый, пусть и н идеальный, инструмент. Мне очевидно, что ты не прав.

Мне очевидно, что это инструмент. И что его готовность это готовность инструмента, а не готовность продукта. Давай ты, как спец по джумле оценишь время:

Создание шаблона на основе дизайна
Дока по языку на вики, wiki движок тоже должен быть в этом дизайне.
Дока по макросам: поиск, отображение, списки по разным критериям на основе внешней информации на твой выбор (xml, база данных)
Дока по стандартной библиотеке с теми же критериаями.
Блог на основе маркапа, чтобы теги там были те же, что и в вики. Адаптация дизайна.

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

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

Потом у меня было знакомство с wordpress, все гораздо приятнее и концептуально логичнее, компоненты лучше стыкуются и все такое. Но! С дизайном та же гадость, некоторые компоненты просто не рассчитаны на дргугие темплейты. Но с вордпрессом я уже понимал, что это временное решение и, поставив его, сразу начал делать свой движок помаленьку.

Тем более форум хочется интегрированный с rsdn, ты хочешь писать интеграцию с rsdn на php?

Здравствуйте, Ziaw, Вы писали:

Z>Мне очевидно, что это инструмент. И что его готовность это готовность инструмента, а не готовность продукта.

То есть изучить инструмент отнимет больше сил, чем создать инструмент?

Z>Давай ты, как спец по джумле оценишь время:

Я не спец по джумле, но у меня есть опыт управления проектами.

Z>

Создание шаблона на основе дизайна
Z>

Дока по языку на вики, wiki движок тоже должен быть в этом дизайне.
Z>

Дока по макросам: поиск, отображение, списки по разным критериям на основе внешней информации на твой выбор (xml, база данных)
Z>

Дока по стандартной библиотеке с теми же критериаями.
Z>

Блог на основе маркапа, чтобы теги там были те же, что и в вики. Адаптация дизайна.
Z>

Ничто из перечисленных пунктов не специфично для конкретного движка. Кстати насчёт дизайна не надо ляля, RSDN вот далеко не пример красоты.

Z>Тем более форум хочется интегрированный с rsdn, ты хочешь писать интеграцию с rsdn на php?

Если интеграция как в статьях, то о какой сложности речь вообще?

И что ты будешь делать с дизайном форума, который не впишется в дизайн сайта?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>Потому что админить их придется мне, хотя бы.

A>Я сейчас админю development environment на линуксовском VDS. Сам. До того админил сам на Windows. Я не админ, просто нанимать было некого (софт сильно специфический) и было время разобраться самому. Учитывая, что к моменту перезда я только-только выучил команду cp, мне Линуксовский сервер админить явно проще.

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

Ну да фиг с ним, если это даст реальные преимущества, то не суть.

KV>>И обеспечивать взаимодействие между VDS, гуглокодом и RSDN4 — тоже.
A>Гуглокод вам вообще не нужен. VCS поставите в том же VDS, напишете пару хуков чтобы билд-сервер дёргать и всё.

после чего нужно будет перенести с гуглокода на VDS багтреккер и обеспечить его интеграцию с VCS и вики. Тут напрашивается разве что только trac, но ради чего нужны все эти телодвижения, когда это уже есть на гуглокоде, я не очень понял

A>Кстати, билд сервер под моно можно поставить на соседней VDS.

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

A>админить изначально линуксовский софт под Линуксом заметно проще.

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

A>Да, идея классная. Я не говорю что идея плохая. Меня волнует, а не надорвётесь ли?

Меня это тоже волнует

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>P.S: Предупреждая следующий вопрос — нет, крестиком я вышивать не умею

A>А я умею вышиват крестиком, и ещё вяжу. Но я не делаю это для других.

Зря

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>И обеспечивать взаимодействие между VDS, гуглокодом и RSDN4 — тоже.
A>>Гуглокод вам вообще не нужен. VCS поставите в том же VDS, напишете пару хуков чтобы билд-сервер дёргать и всё.
KV>после чего нужно будет перенести с гуглокода на VDS багтреккер и обеспечить его интеграцию с VCS и вики. Тут напрашивается разве что только trac, но ради чего нужны все эти телодвижения, когда это уже есть на гуглокоде, я не очень понял

Зависит от целей. Я в своё время из гуглкода просто вырос. Trac это очень очень гибкая система, которая, при правильной настроке, может подойти практически с любому процессу разработки. Я сильно расширил вики, прсото поставив и настроив плагины. Подключил graphviz, настроил особый жизненный цикл тикетов. Для trac есть огромное количество довольно качественных плагинов для всех его частей. Потом, что делать если разные части проекта лицензируются по-разному? Что делат еслич часть проекта закрыта? NRails открытая билиотека, а сам сайт стоит делать открытым? Права доступа в своей инсталляции можно настраивать тоньше. Раздельно на вики и VCS, например.

A>>Кстати, билд сервер под моно можно поставить на соседней VDS.
KV>Нельзя, к сожалению. Под моно не получится собирать интеграцию с VS и инсталятор во-первых, во-вторых сборку проекта под моно колбасит почти с каждой новой минорной версией моно, под нее билд сейчас вообще нельзя закладывать.

Я и не сказал, что надо делать только mono. Я имел ввиду конфигурацию с двумя билд-серверами.

Здравствуйте, adontz, Вы писали:

A>То есть изучить инструмент отнимет больше сил, чем создать инструмент?

Вобщем да, часто на знакомом инструменте сделать быстрее чем на незнакомом. На cms проще и быстрее делать простые вещи. И сложнее сложные. Как только появляется задача, ее тут же надо трансформировать в стиле: так не получится, вместо выпадающего меню придется делать дерево, а сортировка возможна только по дате добавления. Повторюсь, никто из немерлистов не станет писать и поддерживать много кода на php бесплатно. Что делать с этим? Скидываться и нанимать? Так нормальные пхпшники дорогие, а хреновые по факту выйдут еще дороже. Ты оцениваешь решение сиюминутно, без перспектив развития сайта.

Z>>

Z>>

Создание шаблона на основе дизайна
Z>>

Дока по языку на вики, wiki движок тоже должен быть в этом дизайне.
Z>>

Дока по макросам: поиск, отображение, списки по разным критериям на основе внешней информации на твой выбор (xml, база данных)
Z>>

Дока по стандартной библиотеке с теми же критериаями.
Z>>

Блог на основе маркапа, чтобы теги там были те же, что и в вики. Адаптация дизайна.
Z>>

A>Ничто из перечисленных пунктов не специфично для конкретного движка. Кстати насчёт дизайна не надо ляля, RSDN вот далеко не пример красоты.

Ничего не понял из ответа, оцени время не для джумлы, для любой другой CMS на твой выбор.

Z>>Тем более форум хочется интегрированный с rsdn, ты хочешь писать интеграцию с rsdn на php?

A>Если интеграция как в статьях, то о какой сложности речь вообще?

И что ты будешь делать с дизайном форума, который не впишется в дизайн сайта?

Какого форума? Будет свой форум, зеркало этого. RSDN тоже требует обновления, на немерловом будут обкатываться технологии для нового движка rsdn.

Здравствуйте, Ziaw, Вы писали:

A>>Если интеграция как в статьях, то о какой сложности речь вообще?

И что ты будешь делать с дизайном форума, который не впишется в дизайн сайта?
Z>Какого форума? Будет свой форум, зеркало этого. RSDN тоже требует обновления, на немерловом будут обкатываться технологии для нового движка rsdn.

Если ты правда веришь в то, что пишешь, то это крайне печально, потому что тебя ждёт большой облом.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, kochetkov.vladimir, Вы писали:

KV>>>>И обеспечивать взаимодействие между VDS, гуглокодом и RSDN4 — тоже.
A>>>Гуглокод вам вообще не нужен. VCS поставите в том же VDS, напишете пару хуков чтобы билд-сервер дёргать и всё.
KV>>после чего нужно будет перенести с гуглокода на VDS багтреккер и обеспечить его интеграцию с VCS и вики. Тут напрашивается разве что только trac, но ради чего нужны все эти телодвижения, когда это уже есть на гуглокоде, я не очень понял

A>Зависит от целей. Я в своё время из гуглкода просто вырос. Trac это очень очень гибкая система, которая, при правильной настроке, может подойти практически с любому процессу разработки. Я сильно расширил вики, прсото поставив и настроив плагины. Подключил graphviz, настроил особый жизненный цикл тикетов. Для trac есть огромное количество довольно качественных плагинов для всех его частей.

Для процесса разработки гугла хватает, зачем trac? Кто сейчас страдает подобием NIH? А для тех задач про которые я рассказал не хватит trac, даже с кучей его плагинов. Придется писать свои.

A>Потом, что делать если разные части проекта лицензируются по-разному? Что делат еслич часть проекта закрыта? NRails открытая билиотека, а сам сайт стоит делать открытым? Права доступа в своей инсталляции можно настраивать тоньше. Раздельно на вики и VCS, например.

Как всегда, делать проект из тех частей, лицензия которых не накладывает ограничений. Лицензия NRails — MIT, где хочешь там и используй.

A>>>Кстати, билд сервер под моно можно поставить на соседней VDS.
KV>>Нельзя, к сожалению. Под моно не получится собирать интеграцию с VS и инсталятор во-первых, во-вторых сборку проекта под моно колбасит почти с каждой новой минорной версией моно, под нее билд сейчас вообще нельзя закладывать.

A>Я и не сказал, что надо делать только mono. Я имел ввиду конфигурацию с двумя билд-серверами.

Зачем два билдсервера? Моно прекрасно билдится на винде.

Здравствуйте, Ziaw, Вы писали:

Z>Для процесса разработки гугла хватает, зачем trac?

Кому-то хватает, кому-то не очень.

Z>Кто сейчас страдает подобием NIH?

Я что, написал trac?

причём тут NIH?

A>>Потом, что делать если разные части проекта лицензируются по-разному? Что делат еслич часть проекта закрыта? NRails открытая билиотека, а сам сайт стоит делать открытым? Права доступа в своей инсталляции можно настраивать тоньше. Раздельно на вики и VCS, например.
Z>Как всегда, делать проект из тех частей, лицензия которых не накладывает ограничений. Лицензия NRails — MIT, где хочешь там и используй.

Перечиатй вопрос ещё раз, ты его не понял.

A>>Я и не сказал, что надо делать только mono. Я имел ввиду конфигурацию с двумя билд-серверами.
Z>Зачем два билдсервера? Моно прекрасно билдится на винде.

Я думал, понятно, что речь идёт не только о компиляции.

Здравствуйте, adontz, Вы писали:

Z>>Какого форума? Будет свой форум, зеркало этого. RSDN тоже требует обновления, на немерловом будут обкатываться технологии для нового движка rsdn.

A>Если ты правда веришь в то, что пишешь, то это крайне печально, потому что тебя ждёт большой облом.

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

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

Здравствуйте, Ziaw, Вы писали:

Z>Ты снова поскипал все мои вопросы связанные с дороговизной будущей поддержки и развития решения на CMS.

А я и не могу тебе на них ответить. Надо написать ТЗ и разместить заявку, например в форуме Работа — предложения работы от прямых работодателей.

Z>Пока у этих вопросов не будет ответа, вариант с CMS годится только как временное решение. Если есть желающие сделать временное решение — я только за. Но это немалый труд.

А почему т решил что твоё решение не временное или что на него нужно меньше сил?

Здравствуйте, adontz, Вы писали:

Z>>Для процесса разработки гугла хватает, зачем trac?

A>Кому-то хватает, кому-то не очень.

Я не понял, мы перешли с обсуждения нужд nemerle.org на нужды кого-то?

Z>>Кто сейчас страдает подобием NIH?

A>Я что, написал trac?

причём тут NIH?

Проблема в том, что мы используем решение не из тех компонентов, которые советуешь ты. our solutions not invented by adontz.

A>>>Потом, что делать если разные части проекта лицензируются по-разному? Что делат еслич часть проекта закрыта? NRails открытая билиотека, а сам сайт стоит делать открытым? Права доступа в своей инсталляции можно настраивать тоньше. Раздельно на вики и VCS, например.
Z>>Как всегда, делать проект из тех частей, лицензия которых не накладывает ограничений. Лицензия NRails — MIT, где хочешь там и используй.

A>Перечиатй вопрос ещё раз, ты его не понял.

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

Z>>Зачем два билдсервера? Моно прекрасно билдится на винде.

A>Я думал, понятно, что речь идёт не только о компиляции.

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

Здравствуйте, adontz, Вы писали:

A>А я и не могу тебе на них ответить. Надо написать ТЗ и разместить заявку, например в форуме Работа — предложения работы от прямых работодателей.

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

A>А почему т решил что твоё решение не временное или что на него нужно меньше сил?

Мое решение отвечает на вопросы, как развивать и поддерживать. Сил надо тоже много.

Здравствуйте, Ziaw, Вы писали:

A>>Кому-то хватает, кому-то не очень.

Z>Я не понял, мы перешли с обсуждения нужд nemerle.org на нужды кого-то?

А ты разве озвучил нужды nemerle.org?

A>>Я что, написал trac?

причём тут NIH?
Z>Проблема в том, что мы используем решение не из тех компонентов, которые советуешь ты. our solutions not invented by adontz.

SVN и Trac при разработке RSDN светяться. Что тут нового я не знаю. На личности не переходи, получается не конструктивно.

A>>>>Потом, что делать если разные части проекта лицензируются по-разному? Что делат еслич часть проекта закрыта? NRails открытая билиотека, а сам сайт стоит делать открытым? Права доступа в своей инсталляции можно настраивать тоньше. Раздельно на вики и VCS, например.
Z>>>Как всегда, делать проект из тех частей, лицензия которых не накладывает ограничений. Лицензия NRails — MIT, где хочешь там и используй.
A>>Перечиатй вопрос ещё раз, ты его не понял.
Z>Задай вопрос нормально. Лицензионных проблем закрыть проект сайта или его часть я не вижу.

Проблема в том, что на гугл-код это размещать уже будет нельзя.

Z>>>Зачем два билдсервера? Моно прекрасно билдится на винде.
A>>Я думал, понятно, что речь идёт не только о компиляции.
Z>Непонятно. Чем еще будут заниматься два билдсервера кроме сборки и запуска тестов? Ты предлагаешь замутить сервер на линуксе, чтобы ловить баги моно заключающиеся в различном поведении под разными OS? Это да, очень целевой расход ресурсов.

А иначе о какой поддежрке mono идёт речь, если mono не поддерживается на Linux?

Здравствуйте, Ziaw, Вы писали:

A>>А я и не могу тебе на них ответить. Надо написать ТЗ и разместить заявку, например в форуме Работа — предложения работы от прямых работодателей.
Z>У проекта появились спонсоры? Ром, ну зачем толочь воду в ступе, надо решать проблемы исходя из имеющихся ресурсов. А не гипотетической эффективности денег в вакууме

Во-первых, если тебе работодатель платит 10USD в час, то какая разница, подаришь ты проекту час времении или 10USD?
Во-вторых, так тебе специлисты оценят проект и по времени исполнения тоже.

A>>А почему ты решил что твоё решение не временное или что на него нужно меньше сил?

Z>Мое решение отвечает на вопросы, как развивать и поддерживать. Сил надо тоже много.

На вопросы ты не ответил.

Здравствуйте, adontz, Вы писали:

A>>>Кому-то хватает, кому-то не очень.

Z>>Я не понял, мы перешли с обсуждения нужд nemerle.org на нужды кого-то?

A>А ты разве озвучил нужды nemerle.org?

Я думал ты читаешь те сообщения на которые отвечаешь: http://rsdn.ru/forum/nemerle/4154330.1.aspx

A>>>Я что, написал trac?

причём тут NIH?
Z>>Проблема в том, что мы используем решение не из тех компонентов, которые советуешь ты. our solutions not invented by adontz.

A>SVN и Trac при разработке RSDN светяться. Что тут нового я не знаю. На личности не переходи, получается не конструктивно.

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

A>Проблема в том, что на гугл-код это размещать уже будет нельзя.

Сайт немерла? Как это связано с технологиями на которых он сделан?

A>А иначе о какой поддежрке mono идёт речь, если mono не поддерживается на Linux?

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

Здравствуйте, Ziaw, Вы писали:

A>>А ты разве озвучил нужды nemerle.org?
Z>Я думал ты читаешь те сообщения на которые отвечаешь: http://rsdn.ru/forum/nemerle/4154330.1.aspx

Это предложенные тобой решения, а не нужды.

Z>Какие личности? Обвинения в предвзятости выбора компонентов ты выдвинул, я обосновал все решения. Почему ты теперь не желаешь себя затруднить подобным обоснованием?

Ты не выбирал компоненты, ты решил всё написать. А я вообще не настаивал на каком-либо конкретном наборе, просто предложил взять готовое.

A>>Проблема в том, что на гугл-код это размещать уже будет нельзя.
Z>Сайт немерла? Как это связано с технологиями на которых он сделан?

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

A>>А иначе о какой поддежрке mono идёт речь, если mono не поддерживается на Linux?

Z>Ничего не понял, для поддержки моно, надо собрать на моно и прогнать тесты на этой сборке под моно. Если моно собирает или выполняет код на линуксе по другому — это баги моно. В компиляторе из ОС зависимого кода только небольшой кусок работы с файлами, он относительно редко меняется.

Прости, но это жалкая отмазка. Поддерживать Моно только под Windows?! Кому это надо вообще?!

Здравствуйте, adontz, Вы писали:

A>>>А я и не могу тебе на них ответить. Надо написать ТЗ и разместить заявку, например в форуме Работа — предложения работы от прямых работодателей.
Z>>У проекта появились спонсоры? Ром, ну зачем толочь воду в ступе, надо решать проблемы исходя из имеющихся ресурсов. А не гипотетической эффективности денег в вакууме

A>Во-первых, если тебе работодатель платит 10USD в час, то какая разница, подаришь ты проекту час времении или 10USD?

Огромная. Я могу с удовольствием потратить лишний час на хобби и очень редко с удовольствием трачу лишний час на лишние 10$.

A>Во-вторых, так тебе специлисты оценят проект и по времени исполнения тоже.

И что мне с того, что я заставлю специалистов оценивать проект? Если оплачивать его никто не собирается?

A>>>А почему ты решил что твоё решение не временное или что на него нужно меньше сил?

Z>>Мое решение отвечает на вопросы, как развивать и поддерживать. Сил надо тоже много.

A>На вопросы ты не ответил.

Ответил на оба. Читай внимательно.

Здравствуйте, adontz, Вы писали:

A>>>А ты разве озвучил нужды nemerle.org?
Z>>Я думал ты читаешь те сообщения на которые отвечаешь: http://rsdn.ru/forum/nemerle/4154330.1.aspx

A>Это предложенные тобой решения, а не нужды.

К формулировкам докопался? Нужен браузер документации по языку, API и MacroAPI, блог для новостей и статей, wiki, страница для загрузок со ссылками на гуглкод. Все это нужно иметь в одном дизайне, разметка должна использоваться от гуглкода.

A>Ты не выбирал компоненты, ты решил всё написать. А я вообще не настаивал на каком-либо конкретном наборе, просто предложил взять готовое.

Так нет самой сложной части готового. Надо писать. Ты предложил писать под CMS. Из готового можно взять вики и блог, но их тоже придется допиливать. И переносить на чужую вики контент сильно сложнее.

A>>>Проблема в том, что на гугл-код это размещать уже будет нельзя.
Z>>Сайт немерла? Как это связано с технологиями на которых он сделан?

A>Это связано с тем, что с гугл-кода всё равно придётся уехать, даже если он тебе очень нравится.

Кому уехать? Сайту немерла? Так его там и не было.

A>Прости, но это жалкая отмазка. Поддерживать Моно только под Windows?! Кому это надо вообще?!

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

Здравствуйте, adontz, Вы писали:

Z>>Огромная. Я могу с удовольствием потратить лишний час на хобби и очень редко с удовольствием трачу лишний час на лишние 10$.

A>Ну я не виноват что у тебя такая унылая работа

На самом деле разницы никакой.

Скорее у тебя унылое хобби.

A>Это принципиально неправильный подход, делать всё самим. Пусть твоё и его время стоят одинаково. Что лучше, заплатить 100$ специалисту, чтобы он сделал работу за 10 часов или потратить 50 своих часов (500USD), потому что ты не шаришь в вопросе? В итоге всё равно получится хуже. Для меня ответ абсолютно очевиден.

Заплати, я разве против? Чем мне заниматься я сам ерешу.

A>Совершенно не ясно почему твоё решение не временное.

Решение меняют когда оно не может

A>Где гарантия что завтра NRails не будет объявлена морально устаревшей и тебе захочеться всё переписать на новой библиотеке? Ты ведь не хочешь делать сайт на C#, не так ли?

Где гарантия, что завтра на тебе не захочется использовать более подходящую CMS?
Не хочу на C#, потому что есть более мощный язык покрывающий все возможности C#.

A>По поводу сил нет и намёка на ответ.

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

Здравствуйте, Ziaw, Вы писали:

Z>К формулировкам докопался? Нужен браузер документации по языку, API и MacroAPI

Инструменты вроде Sandcastle, NDoc, doxygen генерируют легко стилизуемый набор HTML файлов, которые можно выкладывать на сайт как есть. Впрочем, я думаю что оформление в стиле MSDN пойдёт только на пользу.

Z>блог для новостей и статей, wiki

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

Z>страница для загрузок со ссылками на гуглкод.

Для этого хватит статического HTML.

Z>Все это нужно иметь в одном дизайне, разметка должна использоваться от гуглкода.

Про дизайн документации я уже высказлся.

Z>Так нет самой сложной части готового. Надо писать.

Чего нет-то? VCS — есть, Issue Tracking есть, wiki есть. Твоя проблема не в том, что этого нет, а в том что этого нет под Windows.

Z>Ты предложил писать под CMS.

Как вариант.

Z>Из готового можно взять вики и блог, но их тоже придется допиливать. И переносить на чужую вики контент сильно сложнее.

А что осталось-то кроме вики и блога? Документацяи? Я уже ответил по этому поводу. Страница с ссылками? Маловато чтобы писать свой движок.

A>>Это связано с тем, что с гугл-кода всё равно придётся уехать, даже если он тебе очень нравится.
Z>Кому уехать? Сайту немерла? Так его там и не было.

Вопрос: как удобно работать с несколькими репозиториями если изменения вносяться не только в один из них.

A>>Прости, но это жалкая отмазка. Поддерживать Моно только под Windows?! Кому это надо вообще?!
Z>Это не отмазка, пока сценарий, что тесты проходящие в моно под виндой не проходят в моно под линуком в коде который никак не взаимодействует с платформой не перейдет из разаряда "это возможно в теории", в разряд "есть немалая вероятность" — это достаточная поддержка моно.

Вообще-то, как раз для сценария "это возможно в теории" юнит-тесты и пишутся.

Z>Заводить второй билд сервер для решения несуществующих проблем — бред.

Не надо тогда говорить что моно поддерживается

Итого имеем:

Документация — генерируется существующими инструментами. Лучше работать в направлении поддержки XMLDOC, чем писать движок отображения документации.

VCS — есть.

Wiki — я лично для себя выбрал бы trac, но в сущности выбор огромен. Допилить наиболее подходящую явно быстрее, чем писать свою с нуля.

Блоги — А почему нельзя прикрутить на свой домен ЖЖ или Блогспот? Вроде бы это делается. Standalone блоги пиарить сложнее, нет френдов. Они вообще менее юзабельны для читателя.

Страница с ссылками — Ладно, предполодим что говтой страницы нет.

Как я погляжу маловато мотивов писать свой движок

Здравствуйте, Ziaw, Вы писали:

A>>Это принципиально неправильный подход, делать всё самим. Пусть твоё и его время стоят одинаково. Что лучше, заплатить 100$ специалисту, чтобы он сделал работу за 10 часов или потратить 50 своих часов (500USD), потому что ты не шаришь в вопросе? В итоге всё равно получится хуже. Для меня ответ абсолютно очевиден.
Z>Заплати, я разве против?

Мне вообще говоря не жалко 500 баксов, просто Немерле не настолько нужен, чтобы я за него платил. Я плачу, но за вещи которые нужны мне.

Вообще же проблема хорошо описана тут
http://www.codinghorror.com/blog/2008/07/is-money-useless-to-open-source-projects/comments/

Фанатичное желание делать всё самим приводит управление проекта в состояние, когда что делать с деньгами уже никто не понимает. Это бесперспективный подход. Надо тратить деньги. Надо привлекать специалистов, которых в твоём проекте ничего не интересует. Потому что это способ качественно развивать проект.

A>>Где гарантия что завтра NRails не будет объявлена морально устаревшей и тебе захочеться всё переписать на новой библиотеке? Ты ведь не хочешь делать сайт на C#, не так ли?
Z>Где гарантия, что завтра на тебе не захочется использовать более подходящую CMS?

Разница в поведение адмистраторов и программистов, и только. Что-то я не много видел программистов, которые бы говорили "работает не трогай" и не много видел администраторов, которые бы говорили "этот сервер — говно, переустановить всё на фиг".

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Ziaw, Вы писали:

Z>>К формулировкам докопался? Нужен браузер документации по языку, API и MacroAPI

A>Инструменты вроде Sandcastle, NDoc, doxygen генерируют легко стилизуемый набор HTML файлов, которые можно выкладывать на сайт как есть. Впрочем, я думаю что оформление в стиле MSDN пойдёт только на пользу.

http://nemerle.org/doc/Nemerle.Core.html Ты считаешь это можно держать на сайте?

Z>>блог для новостей и статей, wiki

A>Тут ты не прав. Статьи как раз лучше хранить в вики, а не в блоге. Вики вам нужно две,к ак минимум два раздела вики: для пользователей и для разработчиков. Последний должен быть тесно интегрирован с VCS, первый с Issue Tracking.

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

Z>>страница для загрузок со ссылками на гуглкод.

A>Для этого хватит статического HTML.

С надписью идите ну гуглкод и загружайте? Дешево. Хотя не первой необходимости конечно фича.

Z>>Из готового можно взять вики и блог, но их тоже придется допиливать. И переносить на чужую вики контент сильно сложнее.

A>Вопрос: как удобно работать с несколькими репозиториями если изменения вносяться не только в один из них.

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

A>

A>Итого имеем:

A>Документация — генерируется существующими инструментами. Лучше работать в направлении поддержки XMLDOC, чем писать движок отображения документации.

A>VCS — есть.

A>Wiki — я лично для себя выбрал бы trac, но в сущности выбор огромен. Допилить наиболее подходящую явно быстрее, чем писать свою с нуля.

A>Блоги — А почему нельзя прикрутить на свой домен ЖЖ или Блогспот? Вроде бы это делается. Standalone блоги пиарить сложнее, нет френдов. Они вообще менее юзабельны для читателя.

A>Страница с ссылками — Ладно, предполодим что говтой страницы нет.

A>Как я погляжу маловато мотивов писать свой движок

С таким подходом и сайт не нужен. Вики есть на гуглкоде, доки обновить на текущем сайте и аглы.

Здравствуйте, Ziaw, Вы писали:

A>>Инструменты вроде Sandcastle, NDoc, doxygen генерируют легко стилизуемый набор HTML файлов, которые можно выкладывать на сайт как есть. Впрочем, я думаю что оформление в стиле MSDN пойдёт только на пользу.
Z>http://nemerle.org/doc/Nemerle.Core.html Ты считаешь это можно держать на сайте?

Нет, нельзя. Это бесполезная страница. Однако, это повод улучшить поддержку XMLDOC, а не писать движок сайта.

Z>Статьи нужны и там и там. Именно поэтому разметка должна быть одинаковой и блог с вики тесно интегрироваться.

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

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

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

A>>Как я погляжу маловато мотивов писать свой движок

Z>С таким подходом и сайт не нужен. Вики есть на гуглкоде, доки обновить на текущем сайте и аглы.

Сайт нужен, движок — нет. Это не одно и то же. А подход у меня разумный: я хочу потратив минимум сил получить максимум выгоды.

Здравствуйте, adontz, Вы писали:

Z>>Заплати, я разве против?

A>Мне вообще говоря не жалко 500 баксов, просто Немерле не настолько нужен, чтобы я за него платил. Я плачу, но за вещи которые нужны мне.

Такие понты, тут никому не интересны.

A>Вообще же проблема хорошо описана тут
A>http://www.codinghorror.com/blog/2008/07/is-money-useless-to-open-source-projects/comments/

A>Фанатичное желание делать всё самим приводит управление проекта в состояние, когда что делать с деньгами уже никто не понимает. Это бесперспективный подход. Надо тратить деньги. Надо привлекать специалистов, которых в твоём проекте ничего не интересует. Потому что это способ качественно развивать проект.

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

A>>>Где гарантия что завтра NRails не будет объявлена морально устаревшей и тебе захочеться всё переписать на новой библиотеке? Ты ведь не хочешь делать сайт на C#, не так ли?
Z>>Где гарантия, что завтра на тебе не захочется использовать более подходящую CMS?

A>Разница в поведение адмистраторов и программистов, и только. Что-то я не много видел программистов, которые бы говорили "работает не трогай" и не много видел администраторов, которые бы говорили "этот сервер — говно, переустановить всё на фиг".

Опять понты, во первых ты тоже программист, во вторых я тоже администратор, в третьих фраза — "работает — не трогай" приписывается именно программистам.

Здравствуйте, Ziaw, Вы писали:

A>>Мне вообще говоря не жалко 500 баксов, просто Немерле не настолько нужен, чтобы я за него платил. Я плачу, но за вещи которые нужны мне.
Z>Такие понты, тут никому не интересны.

Ну извини, историю транзакций я тебе предоставлять не буду.

A>>Фанатичное желание делать всё самим приводит управление проекта в состояние, когда что делать с деньгами уже никто не понимает. Это бесперспективный подход. Надо тратить деньги. Надо привлекать специалистов, которых в твоём проекте ничего не интересует. Потому что это способ качественно развивать проект.
Z>Для начала надо понять откуда их получить. Твой способ, скинуться разработчиками, мне категорически не нравится.

Ищи спонсора, кто-то мешает?

Наверняка есть область в которой Немерле очень полезен. Вон разработчики Scala выиграли грант
http://www.scala-lang.org/node/8579
Что мешает вам выграть грант?

Не обязательно такой большой. Одним программированием больших целей не достичь.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Ziaw, Вы писали:

A>>>Инструменты вроде Sandcastle, NDoc, doxygen генерируют легко стилизуемый набор HTML файлов, которые можно выкладывать на сайт как есть. Впрочем, я думаю что оформление в стиле MSDN пойдёт только на пользу.
Z>>http://nemerle.org/doc/Nemerle.Core.html Ты считаешь это можно держать на сайте?

A>Нет, нельзя. Это бесполезная страница. Однако, это повод улучшить поддержку XMLDOC, а не писать движок сайта.

У NDoc и Sandcastle есть одна неподходящая для nemerle особенность, заточенная на C#, они делают доку рефлектором по сборке. doxygen работает с исходниками, но надо научить его парсить код немерла. Либо взять парсер немерла и научиться генерить доки. Можно совместить их, но показывать доки все равно проще на своем сайте, а не

Z>>Статьи нужны и там и там. Именно поэтому разметка должна быть одинаковой и блог с вики тесно интегрироваться.

A>Тебе не нужны статьи в блоге. Нет нормальногго соавторства, нет версионности. Вики с комментариями подходят куда больше блога. Блог хорош для мелких заметок и новостей. Вообще, блог не нужен, вики для статей и твиттер для новостей.

Ну статьи это громко сказано, скорее заметки которые не новости. Возможно потом их захочется перенести в вики. Твиттер да, можно прикрутить.

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

A>NRails в одном репозитории, сайт в другом. Ты пишешь сайт и подправляешь NRails когда не хватает его возможностей. Один разработчик — два активно модифицируемых репозитория. Это очень неудобно.

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

A>Сайт нужен, движок — нет. Это не одно и то же. А подход у меня разумный: я хочу потратив минимум сил получить максимум выгоды.

Ты переоцениваешь выгоду и недооцениваешь сложность поддержки того зоопарка который ты предлагаешь использовать.

Здравствуйте, Ziaw, Вы писали:

Z>У NDoc и Sandcastle есть одна неподходящая для nemerle особенность, заточенная на C#, они делают доку рефлектором по сборке. doxygen работает с исходниками, но надо научить его парсить код немерла. Либо взять парсер немерла и научиться генерить доки. Можно совместить их, но показывать доки все равно проще на своем сайте, а не

Вот и надо заняться генерацией документации. AFAIK Sandcastle никаким рефлектором ничего не обходит, использует XML файлы сгенерированные компилятором C# по XMLDOC. Если подсунуть ему правильные XML файлы, то получится правильный результат. К тому же этот инструмент работает не только с C#, а с VB.Net и MC++. Не знаю работает ли он с F# (наверняка да), но интеграция в популярный существующий инструмент — правильный путь. Кроме того, задача полезна не только для сайта.

A>>Тебе не нужны статьи в блоге. Нет нормальногго соавторства, нет версионности. Вики с комментариями подходят куда больше блога. Блог хорош для мелких заметок и новостей. Вообще, блог не нужен, вики для статей и твиттер для новостей.
Z>Ну статьи это громко сказано, скорее заметки которые не новости. Возможно потом их захочется перенести в вики. Твиттер да, можно прикрутить.

Потому и нужна вики. Кто-то написал {stub}, кто-то другой дополнил. Была заметка, стала статья.

A>>NRails в одном репозитории, сайт в другом. Ты пишешь сайт и подправляешь NRails когда не хватает его возможностей. Один разработчик — два активно модифицируемых репозитория. Это очень неудобно.
Z>Это не проблема. Гораздо хуже, когда тебе приходится подправлять сторонние инструменты.

Ну всегда можно придумать что-то ещё хуже. Это повод оставлять всё как есть.

A>>Сайт нужен, движок — нет. Это не одно и то же. А подход у меня разумный: я хочу потратив минимум сил получить максимум выгоды.
Z>Ты переоцениваешь выгоду и недооцениваешь сложность поддержки того зоопарка который ты предлагаешь использовать.

Ну давай подумаем, пройдёмся по ранее обозначенным пунктам.

Документация
XMLDOC — задача вообще не связанная с сайтом напрямую. На сайте это read-only контент, обычной кучи HTML файлов тут хватит за глаза. Можно настроить скрипт закачки документации с билд-сервера на веб-сервер, если очень уж хочется чтоб всё было совсем круто. Администрировать тут нечего.

VCS
VCS я администрирую сам. У меня был раньше SVN, сейчас есть HG. Тонкие права доступа, горячие бекапы. Ничего сложного нет.

Wiki.
Wiki и тикеты у меня в Trac. Это уже функциональнее чем гуглкод. Шаблоны для дизайна реально очень-очень простые, но дизайн и так "чистый", программистам ничего лучше всё равно не нарисовать. Максимум что стоит сделать, поменять цвета на "корпоративные". Trac я администрирую тоже сам. Не обременительно абсолютно. Время уходит, можно долго возиться пробуя разные плагины (не у всех толковое описание), но это явно на порядки быстрее чем написать своё. Ну и если совсем припёрло Trac замечательно расширяется, я на Питоне начал писать за час когда мне понадобился дополнительный скрипт. Но меня пока не припёрло, а тебя спросить и гуглкода хватает, так что вообще не понятно о чём речь.

Блоги.
Есть так хочеться блогов, прикрутить blogspot.com (http://www.google.com/support/blogger/bin/answer.py?hl=en&answer=55373), и прикрутить твиттер. Один раз настроил и забыл.

Страница с ссылками...
Да, надо написать. Вообще сделать сайт, всякие списки тех кто использует, внешние ссылки, ссылки на страницы вики Getting started, на дистрибутивы стабильных версий разных компонент и т.д. Это уже получается чуть-больше чем сайт-визитка, но явно укладывается в базовые возможности CMS. Какое-то особое администрирование или разработка тут ИМХО не требуются.

Зоопарка я тут не вижу. Будет какая-то VCS (она и так будет), Wiki и тикеты (и дополнительный VCS web view) в Trac, и какая-нибудь CMS. Документация в HTML файлах, движка там нет. Не очень понимаю что тебе не нравится.

Ну кроме того что 1000 часов программирования заменили 20 часами администрирования и ты, как программист, остался без дела.

Здравствуйте, adontz, Вы писали:

A>Ну я не виноват что у тебя такая унылая работа

На самом деле разницы никакой.

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

Хочешь мы сделаем из тебя превержинца немерле всего за каких-то месяц-другой?

Здравствуйте, adontz, Вы писали:

A>Ищи спонсора, кто-то мешает?

Наверняка есть область в которой Немерле очень полезен. Вон разработчики Scala выиграли грант
A>http://www.scala-lang.org/node/8579
A>Что мешает вам выграть грант?

Не обязательно такой большой. Одним программированием больших целей не достичь.

Ром, ну, что ты трепишся то. Ну, найди спонсора. Обещаю тебе 20% отката

.

Потом сделать сайт на немерле — это не просто выполнить каую-то работу. Это означает:
1. Создать интересный фрэймворк для веба.
2. Получить опыт разработки сайтов на немерле.
3. Получить удовольствие от создания новых технологий.
4. Реализовать свои задумки.

Здравствуйте, adontz, Вы писали:

A>А я умею вышиват крестиком, и ещё вяжу. Но я не делаю это для других.

Дык присоеденяйся и сделай сайт для себя.

Здравствуйте, VladD2, Вы писали:

A>>Ну я не виноват что у тебя такая унылая работа

На самом деле разницы никакой.
VD>А я вот уверен, что ты и сам бы с удовольствием поучаствовал бы в создании движка на новых технологиях.
VD>Хочешь мы сделаем из тебя превержинца немерле всего за каких-то месяц-другой?

Что значит хочешь? Зачем мне это? В работе я это применить не смогу, денег на знании Немереле не заработаю. Отдыхаю я последнее время от вещей не связанных с компьютером, хотя работу свою люблю. Мне может быть было бы интересно сделать какую-то коммуникационную платформу, но как бизнес (пусть и не очень доходный, я о форме творчества), а не как полигон для технологий переполненый "матаном". Технологии сами по себе меня не очень волнуют, технологии — это инструмент. Я бы с интересом создал ERP для малый предприятий. Поможет ли мне в этом Немерле?

Здравствуйте, VladD2, Вы писали:

A>>Что мешает вам выграть грант?

Не обязательно такой большой. Одним программированием больших целей не достичь.
VD>Ром, ну, что ты трепишся то. Ну, найди спонсора. Обещаю тебе 20% отката

Я уже нашёл спонсора и получаю 100% отката

VD>1. Создать интересный фрэймворк для веба.
VD>2. Получить опыт разработки сайтов на немерле.

Нужен ли Немерле в вебе? 99% сайтов созданы на отнове CMS, 99% остального внутрикорпоративные разработки в непрофильных предприятиях. Кто будет пользоваться этим фреймворком? Делать прикольные штуки, вне всякого сомнения, прикольно, но если ты хочешь популяризировать язык, то делай полезные штуки.

VD>3. Получить удовольствие от создания новых технологий.
VD>4. Реализовать свои задумки.

Сделай поддержку XMLDOC. Это скучно, но полезно будет всем, а не только веб-программистам.

Мне не нужен сайт

Хорошая GUI библиотека нужна, WinForms — говно, WPF — тормоз и глюк, HTMLayout нихрена не интегрируется как надо. А движок сайта нафиг не упал.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, adontz, Вы писали:

A>>Ищи спонсора, кто-то мешает?

Наверняка есть область в которой Немерле очень полезен. Вон разработчики Scala выиграли грант
A>>http://www.scala-lang.org/node/8579
A>>Что мешает вам выграть грант?

Не обязательно такой большой. Одним программированием больших целей не достичь.

VD>Ром, ну, что ты трепишся то. Ну, найди спонсора. Обещаю тебе 20% отката

.

VD>Потом сделать сайт на немерле — это не просто выполнить каую-то работу. Это означает:
VD>1. Создать интересный фрэймворк для веба.
VD>2. Получить опыт разработки сайтов на немерле.
VD>3. Получить удовольствие от создания новых технологий.
VD>4. Реализовать свои задумки.

1. лучше про откаты в личку.
2. хостинг на моно?
3. У многих моих знакомых сильверран выпелен.
4. Джаваскрипт?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, VladD2, Вы писали:

A>>>Ну я не виноват что у тебя такая унылая работа

На самом деле разницы никакой.
VD>>А я вот уверен, что ты и сам бы с удовольствием поучаствовал бы в создании движка на новых технологиях.
VD>>Хочешь мы сделаем из тебя превержинца немерле всего за каких-то месяц-другой?

A>Что значит хочешь? Зачем мне это? В работе я это применить не смогу, денег на знании Немереле не заработаю. Отдыхаю я последнее время от вещей не связанных с компьютером, хотя работу свою люблю. Мне может быть было бы интересно сделать какую-то коммуникационную платформу, но как бизнес (пусть и не очень доходный, я о форме творчества), а не как полигон для технологий переполненый "матаном". Технологии сами по себе меня не очень волнуют, технологии — это инструмент. Я бы с интересом создал ERP для малый предприятий. Поможет ли мне в этом Немерле?

Да. На немерли можно сделать дсл для 1с.

Здравствуйте, Аноним, Вы писали:

А>Да. На немерли можно сделать дсл для 1с.

В 1C обыный скрипт общего назначения. C#+LINQ вполне подойдут.

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>Да. На немерли можно сделать дсл для 1с.

A>В 1C обыный скрипт общего назначения. C#+LINQ вполне подойдут.

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

Здравствуйте, Аноним, Вы писали:

А>разве они помогут выполнять код 1с?

А зачем мне это?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

А>>разве они помогут выполнять код 1с?

A>А зачем мне это?

Я бы с интересом создал ERP для малый предприятий. Поможет ли мне в этом Немерле?

Здравствуйте, adontz, Вы писали:

A>Могу помочь переехать на Меркуриал и нанести тем самым непоправимую пользу. Я немножеско фанат этой VCS. И могу помочь очень круто настроить Trac. Вам для приличного сайта останется только примитивная CMS и XMLDOC.

Н2 уже на нем. Правда я не очень в восторге от этого. Клиент у нее просто никакой. Хотя несомненно шустрее.

Здравствуйте, adontz, Вы писали:

VD>>Хочешь мы сделаем из тебя превержинца немерле всего за каких-то месяц-другой?

A>Что значит хочешь? Зачем мне это?

А это ты потом сам расскажешь.

A> В работе я это применить не смогу, денег на знании Немереле не заработаю.

Ну, все в жизни меняется.

A>Отдыхаю я последнее время от вещей не связанных с компьютером, хотя работу свою люблю. Мне может быть было бы интересно сделать какую-то коммуникационную платформу, но как бизнес (пусть и не очень доходный, я о форме творчества), а не как полигон для технологий переполненый "матаном". Технологии сами по себе меня не очень волнуют, технологии — это инструмент. Я бы с интересом создал ERP для малый предприятий. Поможет ли мне в этом Немерле?

Безусловно. Но для начала его нужно хорошенько изучить.

Здравствуйте, adontz, Вы писали:

A>Мне не нужен сайт

Хорошая GUI библиотека нужна, WinForms — говно, WPF — тормоз и глюк, HTMLayout нихрена не интегрируется как надо. А движок сайта нафиг не упал.

Ну, там мне тоже не очень. Речь же идет о получении опыта (собственном развитии) и интересном проведении времени.

Гарантирую, что через некоторое время ты сильно изменишь свои представления и станешь лучше как программист (и архитектор).

Здравствуйте, Аноним, Вы писали:

А>1. лучше про откаты в личку.

Дык было бы от чего откатывать.

А>2. хостинг на моно?

На винде.

А>3. У многих моих знакомых сильверран выпелен.
А>4. Джаваскрипт?

У нас свой

Здравствуйте, Аноним, Вы писали:

A>>А зачем мне это?

А>Я бы с интересом создал ERP для малый предприятий. Поможет ли мне в этом Немерле?

А зачем мне при этом копировать богомерский язык скрипта 1С?

Здравствуйте, VladD2, Вы писали:

A>>Могу помочь переехать на Меркуриал и нанести тем самым непоправимую пользу. Я немножеско фанат этой VCS. И могу помочь очень круто настроить Trac. Вам для приличного сайта останется только примитивная CMS и XMLDOC.
VD>Н2 уже на нем. Правда я не очень в восторге от этого. Клиент у нее просто никакой. Хотя несомненно шустрее.

Тортилка? Да, по сравнению с СВНовской она явно слабее. Но вместе с VisualHG большого дискомфорта нет. Больше всего скучаю по автодополнению имён изменившихся файлов.

Здравствуйте, VladD2, Вы писали:

VD>Ну, там мне тоже не очень. Речь же идет о получении опыта (собственном развитии) и интересном проведении времени.

Ну так может сделать что-то полезное не только для себя? Какой-нибудь софт полезный сам по себе, не объязательно именно программистам. Почему бы не сделать стек околопочтовых протоколов (SMTP/POP3/IMAP/NNTP). Задача парсинга текстовых протоколов должна хорошо решаться на Немерле, библиотека будет весьма полезна. Добавь сюда S/MIME парсер/билдер. Это же всё ерутиться вокруг вашего PEG. Протоколы зубодробительные, PIPELINING превращает асинхронный код в нечитаемое месиво. Я вот, помню, написал RegEx Tracer. У меня много планов по поводу новой версии, но всё руки не доходят. А программа была довольно популярной. Почему бы вам не сделать PEG Tracer?

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

A>>>А зачем мне это?

А>>Я бы с интересом создал ERP для малый предприятий. Поможет ли мне в этом Немерле?

A>А зачем мне при этом копировать богомерский язык скрипта 1С?

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

Здравствуйте, adontz, Вы писали:

A>Ну так может сделать что-то полезное не только для себя? Какой-нибудь софт полезный сам по себе, не объязательно именно программистам. Почему бы не сделать стек околопочтовых протоколов (SMTP/POP3/IMAP/NNTP).

Наверно потому что она уже решена и не раз.

A>Задача парсинга текстовых протоколов должна хорошо решаться на Немерле, библиотека будет весьма полезна. Добавь сюда S/MIME парсер/билдер. Это же всё ерутиться вокруг вашего PEG. Протоколы зубодробительные, PIPELINING превращает асинхронный код в нечитаемое месиво. Я вот, помню, написал RegEx Tracer. У меня много планов по поводу новой версии, но всё руки не доходят. А программа была довольно популярной. Почему бы вам не сделать PEG Tracer?

Немерл для этой задачи наверно будет идеальным инструментом. Вопрос только в мотивации. Лично мне сетевые протоколы просто не интересны. Заниматься такой задачей я стал бы только если кто-то предложил бы за это достойные деньги.

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

Здравствуйте, VladD2, Вы писали:

A>>Ну так может сделать что-то полезное не только для себя? Какой-нибудь софт полезный сам по себе, не объязательно именно программистам. Почему бы не сделать стек околопочтовых протоколов (SMTP/POP3/IMAP/NNTP).
VD>Наверно потому что она уже решена и не раз.

Ну платных-то библиотек дофига, речь об FOSS альтернативе.

A>>Задача парсинга текстовых протоколов должна хорошо решаться на Немерле, библиотека будет весьма полезна. Добавь сюда S/MIME парсер/билдер. Это же всё ерутиться вокруг вашего PEG. Протоколы зубодробительные, PIPELINING превращает асинхронный код в нечитаемое месиво. Я вот, помню, написал RegEx Tracer. У меня много планов по поводу новой версии, но всё руки не доходят. А программа была довольно популярной. Почему бы вам не сделать PEG Tracer?
VD>Лично мне сетевые протоколы просто не интересны.

S/MIME это формат хранения, а не сетевой протокол. Если ты фанат Немерле, тогда делай что хочешь. Если популяризатор, тогда акценты надо немножечко сместить.

Здравствуйте, adontz, Вы писали:

Z>>У NDoc и Sandcastle есть одна неподходящая для nemerle особенность, заточенная на C#, они делают доку рефлектором по сборке. doxygen работает с исходниками, но надо научить его парсить код немерла. Либо взять парсер немерла и научиться генерить доки. Можно совместить их, но показывать доки все равно проще на своем сайте, а не

A>Вот и надо заняться генерацией документации.

Займемся ) Считаешь, что без тебя не догадались?

A>AFAIK Sandcastle никаким рефлектором ничего не обходит, использует XML файлы сгенерированные компилятором C# по XMLDOC. Если подсунуть ему правильные XML файлы, то получится правильный результат. К тому же этот инструмент работает не только с C#, а с VB.Net и MC++. Не знаю работает ли он с F# (наверняка да), но интеграция в популярный существующий инструмент — правильный путь. Кроме того, задача полезна не только для сайта.

Не надо писать афайк, если тебе лень глянуть на сайт проекта. Там первым абзацом написано.

Sandcastle produces accurate, MSDN style, comprehensive documentation by reflecting over the source assemblies and optionally integrating XML Documentation Comments. Sandcastle has the following key features:

* Works with or without authored comments
* Supports Generics and .NET

Ну и коментарий внизу радует:

hahaha signed up just to tell you I agree, I just installed and was hoping for a convenient NDoc replacement. No documentation and no clue what exactly to do next ... except for digging around of course Great effort though, won´t complain about that.

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

A>Потому и нужна вики. Кто-то написал {stub}, кто-то другой дополнил. Была заметка, стала статья.

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

A>>>NRails в одном репозитории, сайт в другом. Ты пишешь сайт и подправляешь NRails когда не хватает его возможностей. Один разработчик — два активно модифицируемых репозитория. Это очень неудобно.
Z>>Это не проблема. Гораздо хуже, когда тебе приходится подправлять сторонние инструменты.

A>Ну всегда можно придумать что-то ещё хуже. Это повод оставлять всё как есть.

Так ты же нам советуешь, взять и допилить кучу инструментов

A>Ну давай подумаем, пройдёмся по ранее обозначенным пунктам.

A>Документация
A>XMLDOC — задача вообще не связанная с сайтом напрямую. На сайте это read-only контент, обычной кучи HTML файлов тут хватит за глаза. Можно настроить скрипт закачки документации с билд-сервера на веб-сервер, если очень уж хочется чтоб всё было совсем круто. Администрировать тут нечего.

А потом захочется обсуждения, как в http://php.net/manual/en/function.strpos.php

A>VCS
A>VCS я администрирую сам. У меня был раньше SVN, сейчас есть HG. Тонкие права доступа, горячие бекапы. Ничего сложного нет.

Ты забыл спросить, нужна ли нам VCS на сайте языка.

A>Wiki.
A>Wiki и тикеты у меня в Trac. Это уже функциональнее чем гуглкод. Шаблоны для дизайна реально очень-очень простые, но дизайн и так "чистый", программистам ничего лучше всё равно не нарисовать. Максимум что стоит сделать, поменять цвета на "корпоративные". Trac я администрирую тоже сам. Не обременительно абсолютно. Время уходит, можно долго возиться пробуя разные плагины (не у всех толковое описание), но это явно на порядки быстрее чем написать своё. Ну и если совсем припёрло Trac замечательно расширяется, я на Питоне начал писать за час когда мне понадобился дополнительный скрипт. Но меня пока не припёрло, а тебя спросить и гуглкода хватает, так что вообще не понятно о чём речь.

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

A>Блоги.
A>Есть так хочеться блогов, прикрутить blogspot.com (http://www.google.com/support/blogger/bin/answer.py?hl=en&answer=55373), и прикрутить твиттер. Один раз настроил и забыл.

Это мысль, надо обдумать.

A>Ну кроме того что 1000 часов программирования заменили 20 часами администрирования и ты, как программист, остался без дела.

Оставь меня без дела, плиз, умоляю. У меня хватает забот и без этого сайта.

Здравствуйте, Ziaw, Вы писали:

A>>Вот и надо заняться генерацией документации.
Z>Займемся ) Считаешь, что без тебя не догадались?

Считаю, что это не повод писать сайт.

Z>Я хз, сколько времени сэкономит недокументированное изделие парня из индии, но есть серьезные опасения, что настраивать его можно только правкой исходного кода.

Как ты уже заметил, есть альтернативы Sandcastle.

Не допилить, а настроить. Допилить я предлагаю компилятор.

Z>А потом захочется обсуждения, как в http://php.net/manual/en/function.strpos.php

Да, но задача генерации документации от этого никуда не денется. И даже это можно легко решить каким-нибудь <iframe>.

Z>Ты забыл спросить, нужна ли нам VCS на сайте языка.

Не совсем ясно что такое сайт языка, если с него нельзя скачать исходники.

Z>Ты забыл спросить, нужны ли нам тикеты на сайте языка. Я ставил и администрил trac и знаю про его плагины, trac не нужен.

Не совсем ясно что такое сайт языка, если нельзя отправить баг-репорт.

A>>Ну кроме того что 1000 часов программирования заменили 20 часами администрирования и ты, как программист, остался без дела.
Z>Оставь меня без дела, плиз, умоляю. У меня хватает забот и без этого сайта.

Если бы ты не упирался, а взглянул на вещи объективно, ты бы понял что я предлагаю достаточно качественное решение значительно меньшими усилиями.

Я уже сказал, спуститесь на землю, помогу всё спланировать и настроить. Хотите писать движок сайта, тоже пожалуйста, но я это считаю нерациональной тратой времени.

Здравствуйте, adontz, Вы писали:

A>>>Как ты уже заметил, есть альтернативы Sandcastle.

A>    http://www.ruby-lang.org/ сайт
A>http://redmine.ruby-lang.org/ трекер

A>    http://www.python.org/    сайт
A>   http://bugs.python.org/    трекер
A>

A>Не вижу тут никаких внещних систем.

В руби redmine стоит отдельно, в boo jira стоит отдельно, на основных сайтах только ссылки туда. В питоне действительно встроили, но это выглядит не очень удобно. Вывод — на сайте трекер не нужен, нужна ссылка на внешний.

A>>>Я уже сказал, спуститесь на землю, помогу всё спланировать и настроить. Хотите писать движок сайта, тоже пожалуйста, но я это считаю нерациональной тратой времени.
Z>>Я на земле и прекрасно вижу, что ты не хочешь ничего делать, но желаешь порулить и поучить. Не заморачиваясь хоть какой-то ответственностью за свои решения, будущее языка и сайта тебя абсолютно не трогает.

A>Прости, но хаму помогать желания нет

Не надо называть хамством все, что тебе неприятно слышать. Ты утверждал, что будущее языка тебе неинтересно, что тратить деньги на него не будешь, что тратить время для тебя то же самое, что тратить деньги. А потом на чистом глазу — "вот еслиб мне тут не хамили, я б вам конечно помог".

Trac и hg я настраивал и сам, там нет рокетсаенса и необходимости привлекать сторонних экспертов.

Здравствуйте, adontz, Вы писали:

A>Если ты фанат Немерле, тогда делай что хочешь. Если популяризатор, тогда акценты надо немножечко сместить.

У меня слишком много других задач, чтобы заниматься тем, что мне не интересно и к тому же мало кому будет нужно.

Популярности от написания подобной библиотеки точно не прибавится. Это весьма специфичный сегмент ПО. Большая часть людей делает веб-сайты и им совершенно все равно на чем написан HTTP.

Так что повторюсь еще раз. Если тебе интересна данная задача, то берись за нее и делай. Я могу в этом тебе помочь. Но не для популяризации чего-то там, просто по человечески.

Здравствуйте, VladD2, Вы писали:

A>>Если ты фанат Немерле, тогда делай что хочешь. Если популяризатор, тогда акценты надо немножечко сместить.
VD>У меня слишком много других задач, чтобы заниматься тем, что мне не интересно и к тому же мало кому будет нужно.

Сделай то что будет нужно многим

Ещё один движок сайта, под Windows на непонятном языке вряд ли станет популярным продуктом. Если вы его вообще доведёте до состояния продукта.

VD>Так что повторюсь еще раз. Если тебе интересна данная задача, то берись за нее и делай. Я могу в этом тебе помочь. Но не для популяризации чего-то там, просто по человечески.

Задача мне интересна, делать её на Немерле не очень. Я сейчас набрасываю архитектуру, а потом перепоручаю доделывать мелочи другим людям. С Немерле мне придётся всё делать самому. Экономически это не выгодно.

Здравствуйте, Ziaw, Вы писали:

A>>Я отмечаю, что могут быть разные варианты решения проблемы.
Z>Так зачем из этих разных предлагать откровенный фейл?

Откровенный фейл это патчить Sandcastle. Завтра выдет версия с новой фичей, которой в твоей версии не будет. Ну и два Sandcasle тоже на фиг никому не упали. Правильнее поддерживать интеграционную прослойку, какой бы страшненькой она ни была.

A>>Знаешь, идеализм мешает придти к результату. Ты это называй костылями, я это называю интеграцией.
Z>Угу, а поддерживать такую интеграцию придется нанять индусов.

Иногда и такое решение правильно. Решение надо оценивать не со стороны внутренней красоты. Пользователям решение работающее с Sandcastle без его переделок, очевидно, удобнее. Его проще внедрять, им проще пользоваться. А ты хочешь чтобы они платили за удовлетворения твоего чувства вкуса. Этот путь не приведёт к успеху.

A>>Я уже тебе объяснил почему своя VCS потребуется. Если уж делаешь свою, то и храни всё в своей.
Z>Ничего ты не объяснил. На сайте это не нужно.

Если ты закрыл уши, это не значит что я просто шлёпал губами

Z>В руби redmine стоит отдельно, в boo jira стоит отдельно, на основных сайтах только ссылки туда. В питоне действительно встроили, но это выглядит не очень удобно. Вывод — на сайте трекер не нужен, нужна ссылка на внешний.

Ты начинаешь путать понятия, это печально. Там отдельный софт (не ты ли хотел всё сделать в одном движке?), но это не внешний трекер. Это у вас внешний трекер.

Z>Не надо называть хамством все, что тебе неприятно слышать. Ты утверждал, что будущее языка тебе неинтересно, что тратить деньги на него не будешь, что тратить время для тебя то же самое, что тратить деньги.

Я сказал что будущее языка мне не настолько интересно, чтобы приобретать связанные с ним активы. ещё я сказал, что иногда потратить деньги эффективне, чем потратить время. Ты всё понял так как тебе хотелось, а не так как имелось ввиду. Это твоя личная проблема.

Z>А потом на чистом глазу — "вот еслиб мне тут не хамили, я б вам конечно помог".

Я вам и сейчас помогу, просто перестань меня обвинять в отсутсвии интереса. Ещё пяти миллиардам людей плевать и на Немерле и на тебя лично. Все враги, всех расстрелять?

Z>Trac и hg я настраивал и сам, там нет рокетсаенса и необходимости привлекать сторонних экспертов.

Ты мыслишь как программист. У тебя нет ни дальновидности чтобы понять как вести проект, ни опыта чтобы знать как вести проект. Писать всё самому — путь в никуда.

Здравствуйте, adontz, Вы писали:

Z>>А потом на чистом глазу — "вот еслиб мне тут не хамили, я б вам конечно помог".

A>Я вам и сейчас помогу, просто перестань меня обвинять в отсутсвии интереса. Ещё пяти миллиардам людей плевать и на Немерле и на тебя лично. Все враги, всех расстрелять?

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

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

Z>>Trac и hg я настраивал и сам, там нет рокетсаенса и необходимости привлекать сторонних экспертов.

A>Ты мыслишь как программист. У тебя нет ни дальновидности чтобы понять как вести проект, ни опыта чтобы знать как вести проект. Писать всё самому — путь в никуда.

Ржу. Кроме перехода на личности ответить на эту фразу оказалось нечего? Что тебя так в ней задело?

Здравствуйте, Ziaw, Вы писали:

Z>Помогай Владу, ему явно требуется идея для сетевого приложения которое покорит мир.

Сеть я уже предложил, он не хочет.

Z>Языку требуется сайт, хочешь делать подключайся, обсудим. Хочешь, чтобы другие делали — не мешай, люди который непосредственно в теме знают про имеющиеся инструменты не хуже тебя. Тебя расслабила ситуация, когда у тебя появились люди которые выполняют твои хотелки не особо включая мозг. Прими совет, от человека у которого такие люди уже лет 7, доделывай иногда свои вещи сам. Сильно прочищает мозг с уклоном в "архитектора" и "администратора".

Если бы ты почитал внимательно, ты бы заметил, что я как раз предлагал всё сделать сам. Но ведь читать чужое не так интересно, как писать своё, не так ли? Как хорошо ты знаешь конкретные инструменты и знаешь ли их лучше меня — вопрос открытый и перепиской в форуме его не решить. Если бы у тебя был чёткий список сценариев использования и требований, то было бы что обсуждать. Сейчас я вынужден угадывать что надо и слышать в ответ что угадал не правильно. Я знаю что я видел на сайтах других языков, знаю что мне нравилось и не нравилось. Если у тебя есть какое-то ТЗ, то огласи. Если нет, то мы сейчас обсуждаем моё виденье решения, основанное на догадках о твоём виденьи проблемы. Занятие малополезное.

Z>>>Trac и hg я настраивал и сам, там нет рокетсаенса и необходимости привлекать сторонних экспертов.
A>>Ты мыслишь как программист. У тебя нет ни дальновидности чтобы понять как вести проект, ни опыта чтобы знать как вести проект. Писать всё самому — путь в никуда.
Z>Ржу. Кроме перехода на личности ответить на эту фразу оказалось нечего? Что тебя так в ней задело?

Я констатирую факт. Ты не занимаешься исследованием существующих средств, не пытаешься интегрироваться в другие инструменты .Net, ты пытаешься всё переписать. Sandcastlle неправильный, надо его переписать. Вики неправильная, надо её переписать. CMS неправильные, надо их переписать. И всё на Немерле, иначе не круто! Я пытаюсь тебе помочь вернуться в конструктивное русло и постараться построить решение на основе существующих средств, получив максимальное отношение результат/ресурсы при приемлемом качестве. Ты, всё чем пользуются не только создатели языков, но и многих библиотек, назвал костылями и слушать ничего не хочешь.

Мне уже не интересно общаться с таким упёртым человеком, общение с тобой отталкивает и от тебя, и от Немерле.

Здравствуйте, adontz, Вы писали:

A>Сделай то что будет нужно многим

Ещё один движок сайта, под Windows на непонятном языке вряд ли станет популярным продуктом. Если вы его вообще доведёте до состояния продукта.

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

A>Задача мне интересна, делать её на Немерле не очень. Я сейчас набрасываю архитектуру, а потом перепоручаю доделывать мелочи другим людям. С Немерле мне придётся всё делать самому. Экономически это не выгодно.

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

Здравствуйте, VladD2, Вы писали:

A>>Сделай то что будет нужно многим

Ещё один движок сайта, под Windows на непонятном языке вряд ли станет популярным продуктом. Если вы его вообще доведёте до состояния продукта.
VD>Сайт нужен нам самим. Так что популярность тут не причем. Но в процессе создания сатйта можно отработать технологии веб-разработки. Движок ренедеренга, Рельсы и т.п. Вот это уже может быть интересно окружающим.

Популярность всего этого (как и доведения до состояния продукта) вызывают абсолютно аналогичные сомнения.

A>>Задача мне интересна, делать её на Немерле не очень. Я сейчас набрасываю архитектуру, а потом перепоручаю доделывать мелочи другим людям. С Немерле мне придётся всё делать самому. Экономически это не выгодно.
VD>Не удивлюсь, если на немерле в одиночку ты справишься с задачей быстрее чем кучей народа на шарпе. Ну, да опять же твое дело. Я тебе это предложил только чтобы ты познакомился с тем что ты периодически критикуешь или обсуждаешь.

Nemerle — замечательный язык. Но этого мало для массового использования. Ы?

Здравствуйте, adontz, Вы писали:

A>Популярность всего этого (как и доведения до состояния продукта) вызывают абсолютно аналогичные сомнения.

Ром, а что у тебя не вызывает сомнений? Библиотека для сетевых протоколов?

A>Nemerle — замечательный язык. Но этого мало для массового использования. Ы?

Ну, да КО. Вот даже ты лясы точишь, а попробовать не хочешь.

Здравствуйте, VladD2, Вы писали:

A>>Популярность всего этого (как и доведения до состояния продукта) вызывают абсолютно аналогичные сомнения.
VD>Ром, а что у тебя не вызывает сомнений? Библиотека для сетевых протоколов?

Почтовые сообщения — достаточно стандартный способ передачи информации. Библиотека протоколов была бы полезна при интеграционных работах. Таких работ при любом внедрении достаточно много. Я не то чтобы абсолютно уверен, что это будет популярно, но я чётко представляю себе рыночную нишу: кому и когда это может быть нужно. Рыночной ниши для того что ты предлагаешь я попросту не вижу. Кроме того, я уже писал подобную библиотеку на C# и представляю себе с каками трудностями можно столкнуться. Я не настаиваю на конкретном продукте, можно писать что-то другое, лишь бы массовое.

A>>Nemerle — замечательный язык. Но этого мало для массового использования. Ы?
VD>Ну, да КО. Вот даже ты лясы точишь, а попробовать не хочешь.

Дело не в том, что я принципиально не хочу попробовать. Дело в том, что кодогенерация (пресловутый Т4) даёт дополнительные возможности (заметно меньше, чем у Nemerle, но для дела хватает) и гораздо более понятна рядовому программисту. Даже внедрение Т4 было многократно обдумано, взвешено и т.д., хотя это официально поддерживаемый продукт. Т4 не требует изучения нового подхода (HTML на PHP генерируется так же), не требует изучения языка (внутри тот же C#), но и это было не просто. Я не могу использовать в задаче ничего, что помешает перепоручению задачи. Это политика управления проектами. Что же делать, как же агитировать? Какое-нибудь полезное FOSS приложение было бы кстати. Было бы доказательство, что на Немереле можно выпустить продукт, а не просто писать всякие интересные штуки. Можно было бы читая его исходники понимать как делать те или иные вещи. Я, при всём своё желании, могу протолкнуть Немерле в продакшн только стуча ботинком по трибуне. А вот проталкивать его таким способом я не считаю правильным. Я не фанат Немерле, но может и был бы не против помочь написать на Немерле что-то такое, что было бы и мне полезно. Не интересно писать, а приятно использовать. Должен получиться массовый продукт, а не очередная прикольная штука.

Здравствуйте, adontz, Вы писали:

A>Если бы ты почитал внимательно, ты бы заметил, что я как раз предлагал всё сделать сам.

Ссылки в студию. Я видел только, что ты предлагал внедрить меркуриал, поставить трэк и помочь советом. Ни то ни другое не требуется.

A>Но ведь читать чужое не так интересно, как писать своё, не так ли? Как хорошо ты знаешь конкретные инструменты и знаешь ли их лучше меня — вопрос открытый и перепиской в форуме его не решить. Если бы у тебя был чёткий список сценариев использования и требований, то было бы что обсуждать. Сейчас я вынужден угадывать что надо и слышать в ответ что угадал не правильно. Я знаю что я видел на сайтах других языков, знаю что мне нравилось и не нравилось. Если у тебя есть какое-то ТЗ, то огласи. Если нет, то мы сейчас обсуждаем моё виденье решения, основанное на догадках о твоём виденьи проблемы. Занятие малополезное.

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

Z>>>>Trac и hg я настраивал и сам, там нет рокетсаенса и необходимости привлекать сторонних экспертов.
A>>>Ты мыслишь как программист. У тебя нет ни дальновидности чтобы понять как вести проект, ни опыта чтобы знать как вести проект. Писать всё самому — путь в никуда.
Z>>Ржу. Кроме перехода на личности ответить на эту фразу оказалось нечего? Что тебя так в ней задело?

A>Я констатирую факт. Ты не занимаешься исследованием существующих средств, не пытаешься интегрироваться в другие инструменты .Net, ты пытаешься всё переписать. Sandcastlle неправильный, надо его переписать. Вики неправильная, надо её переписать. CMS неправильные, надо их переписать. И всё на Немерле, иначе не круто! Я пытаюсь тебе помочь вернуться в конструктивное русло и постараться построить решение на основе существующих средств, получив максимальное отношение результат/ресурсы при приемлемом качестве. Ты, всё чем пользуются не только создатели языков, но и многих библиотек, назвал костылями и слушать ничего не хочешь.

Мне уже не интересно общаться с таким упёртым человеком, общение с тобой отталкивает и от тебя, и от Немерле.

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

Все генераторы док для .net которые я смотрел, либо устарели либо работают через рефлекшн либо все вместе. Между тем, у немерле есть особенности, которые делают сгенеренный IL далеким от того, что требуется документировать. Поэтому единственный рабочий способ это парсить исходники. Распарсенный выход потом возможно скормим генератору док, возможно сами сгенерируем доки, этот вопрос еще не решался. Но ты прекрасно понимаешь, что генерация html по готовому дереву задача вполне сравнимая с генерацией специфического входа в тот же sandcastle, только вот особенностей nemerle он учесть никак не сможет.

Как видишь, пока ничего не делается для того, чтобы все написать с нуля. Смотрятся другие варианты. По любому будет какой-то свой сайт который будет служить клеем для всего остального. Поскольку все дотнетчики он будет на asp.net mvc.

О вики пока только мысли, к ней пока есть простые требования: понимать формат гуглкода и формат rsdn. Самый расширяемый вики движок который я видел, это xwiki, он такое легко организует. Но это монстр в стиле java enterprise

Пхпшные вики отметаются так же как и java, по религиозным причинам. Остаются .net, python, ruby. Если есть желание помочь — пройдись по стеку, присмотри вики которую легко интегрировать в asp.net mvc приложение.

Здравствуйте, Ziaw, Вы писали:

A>>Если бы ты почитал внимательно, ты бы заметил, что я как раз предлагал всё сделать сам.
Z>Ссылки в студию. Я видел только, что ты предлагал внедрить меркуриал, поставить трэк и помочь советом. Ни то ни другое не требуется.

http://www.rsdn.ru/forum/nemerle/4154273.1.aspx

P.S. Я могу вам всё это настроить, но покупать linode не буду, потому что не хочу владеть активами связанными с Nemerle.

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

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

Z>Рома, вот скажи мне одну вещь. Откуда ты знаешь, чем я занимаюсь, а чем нет? По сайту пока делается две задачи: дизайн и выдергивание из исходников синтаксиса и комментариев к макросам. Эту проблему не решит ни один имеющийся сейчас генератор документации.

Это значит, что надо помочь существующим генераторам, а не городить свой.

Z>Но ты прекрасно понимаешь, что генерация html по готовому дереву задача вполне сравнимая с генерацией специфического входа в тот же sandcastle, только вот особенностей nemerle он учесть никак не сможет.

Для популяризации задача совметимости с Sandcastle важнее задачи генерации документации учитывающей все особенности Nemerle.

Z>Поскольку все дотнетчики он будет на asp.net mvc.

Вот это я и называю мыслить как программист.

Здравствуйте, adontz, Вы писали:

A>http://www.rsdn.ru/forum/nemerle/4154273.1.aspx
A>

P.S. Я могу вам всё это настроить, но покупать linode не буду, потому что не хочу владеть активами связанными с Nemerle.

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

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

A>Подобный ответ свидетельствует лишь о том, что опыта управления проектами у тебя нет. Как ты можешь стремиться к цели, если у тебя нет чётко обозначенной цели?

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

Z>>Но ты прекрасно понимаешь, что генерация html по готовому дереву задача вполне сравнимая с генерацией специфического входа в тот же sandcastle, только вот особенностей nemerle он учесть никак не сможет.

A>Для популяризации задача совметимости с Sandcastle важнее задачи генерации документации учитывающей все особенности Nemerle.

Возможно. Если он окажется способен настолько настраиваться. Допиливать генерацию кода под него — точно плохая идея. Кто-то еще потребует для популяризации совместимость с рефлектором, что делать?

Z>>Поскольку все дотнетчики он будет на asp.net mvc.

A>Вот это я и называю мыслить как программист.

Чушь какая-то. Не ты ли тут не хотел использовать nemerle, потому, что команда его не знает? В воздухе витает требование встроить на сайт repl, ты считаешь, что хостить .net приложение в другом стеке будет удобно?

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

Возьмите переведенные статьи Влада(некоторые вроде переведены, так?), добавьте официальную документацию с сайта nemerle.org(которую хрен найдешь сразу) и выложите ее на немерле гугл код — на главную страницу!!!!!!!! Сделайте это прямо сейчас. Хотя бы ссылки. Только сделайте нормальное структурирование, а не то что сейчас Grokking_Nemerle, Macros, Tutorials_and_examples — хрен поймешь. В идеале кончено было бы хорошо поменять бесконечно унылый дизаян официальной документации и привести ее в актуальное состояние. Сейчас пользователь видит: русский форум(кому он нафиг нужен кроме нас самих; группы гугл, где одно сообщение в пол года; двe ссылки ("webpage" — lowut?) на сайты nemerle.org\nemerle.net с дизайном от которого хочется накрыться подушкой и плакать). Дайте мне права — я сам покурочу.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

Здравствуйте, Ziaw, Вы писали:

Z>Там ты предлагал уехать с гуглкода. Не спросив разработчиков, хотят ли они уехать.

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

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

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

Z>В недалеком будущем появится nemerle 2 со своими требованиями.

Были прецеденты координального переделывания сайта посвященного какому-либо продукту, вызванного большими изменениями в продукте?

Твои завления меня удивляют всё больше.

A>>Для популяризации задача совметимости с Sandcastle важнее задачи генерации документации учитывающей все особенности Nemerle.
Z>Возможно. Если он окажется способен настолько настраиваться. Допиливать генерацию кода под него — точно плохая идея. Кто-то еще потребует для популяризации совместимость с рефлектором, что делать?

Написать для рефлектора LanguageWriter. Я у себя в рефлекторе вижу язык Oxygene, понятия не имею что за язык, вижу F#. Но ты видимо будешь писать свой, альтернативный, рефлектор.

Z>>>Поскольку все дотнетчики он будет на asp.net mvc.
A>>Вот это я и называю мыслить как программист.
Z>Чушь какая-то. Не ты ли тут не хотел использовать nemerle, потому, что команда его не знает?

То что я предлагал вообще не должно требовать знания языка. И ты вот знаешь Питон и PHP. Наверняка многие знают. Так что в чём проблема, кроме понтов решать все задачи на одном языке?

Z>В воздухе витает требование встроить на сайт repl, ты считаешь, что хостить .net приложение в другом стеке будет удобно?

Ну если бы поддержка моно была бы всамделишной, такой проблемы бы не стояло.

Z>Дискуссию я закрываю. Игнор того, чем ты мог действительно помочь говорит сам за себя.

Да ну, и чем же? Потворствовать твоему фанатизму? Нет, уволь. Я за адекватные решения, а у тебя сплошной NIH.

Здравствуйте, Ziaw, Вы писали:

Со всем сказанным согласен кроме:

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

На самом деле давным давно документация генерировалась чем-то вроде Сендкасла. И генерировалась она не так уж плохо.

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

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

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

Вся остальная информация о макросах есть в самих макросах. Там и синтаксис описывается и все остальное:

  /** Interface, which will be implemented by class encapsulating macro
      function. It will allow dynamic execution of macro by compiler
      itself
   */
  public interface IMacro
  {
    GetName () : string;
    GetNamespace () : string;  
    Run (ctx : Typer, args : list [SyntaxElement]) : PExpr;
    CallTransform (_ : list [PExpr]) : list [SyntaxElement];
    SyntaxExtension () : GrammarElement * (list [SyntaxElement] -> list [SyntaxElement]);
    IsTailRecursionTransparent : bool { get; }
    IsInherited : bool { get; }
    Keywords : list [string] { get; }
    Usage : MacroUsageAttribute { get; }
    Location : Location { get; }
  }

Создать не хитрую программу которая бы вынимала список макросов и формирует по нему ХТМЛ задача на один вечер.

Все что нам нужно — это добавить к этому интерфейсу информацию из док.коментов.

Здравствуйте, VladD2, Вы писали:

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

VD>На самом деле давным давно документация генерировалась чем-то вроде Сендкасла. И генерировалась она не так уж плохо.

Не так уж плохо там где не особо применяется метапрограммирование.

class A
{
   /// <summary>
   ///  i member documentation
   /// </summary>
   [Accessor] i : int = 42;
}

Можно и других примеров в придумать.

Это конечно не так уж критично, по большому счету.

VD>Единственный вопрос который имеется — это документация для макросов. С ней проблема, так с одной стороны макросы нестандартная сущность и документацию для них просто некуда положить, а с другой ее попросту нет.

VD>Так что по уму сначала нужно было бы решить эту проблему в компиляторе. Можно засовывать док-коменты в некий атрибут или так же как стандартные в хмл-файл, но при этом нужно разобраться с форматом.

+1. Это и в IDE поможет и макрос Accessor может перенести доку в свойство. Только атрибут это плохая идея.

VD>В любом случае хорошо бы иметь хинты в среде разработки. Их с исходников точно не сделать, если макрос пришел в виде библиотеки.

Из исходников надо генерить xml к dll, как делает компилятор C#, только вот все генераторы (типа sandcastle) кроме xml берут сборку и тупо выдирают все классы и все публичные методы рефлектором. По ним генерят доку, приджойнивая слева xml, а в генерируемом коде, кмк, есть сущности которые не хотелось бы туда помещать. Например анонимные типы.

Но есть еще один класс генераторов док, самый известный — doxygen, он курочит исходники (или то, что ты ему дашь в качестве исходников). Он вообще настраивается по самое не балуй, с ним можно попробовать поиграться.

VD>Вся остальная информация о макросах есть в самих макросах. Там и синтаксис описывается и все остальное:
VD>Создать не хитрую программу которая бы вынимала список макросов и формирует по нему ХТМЛ задача на один вечер.

Я в курсе.

VD>Все что нам нужно — это добавить к этому интерфейсу информацию из док.коментов.

Не только к этому.

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	13.02.11 15:52
Оценка:	47 (1) +2

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	10.02.11 15:24
Оценка:	47 (1) +1

	От:	Ka3a4oK
	Дата:	13.02.11 14:03
	Оценка:	47 (1) +1

От:	kochetkov.vladimir	https://kochetkov.github.io
Дата:	11.02.11 21:25
Оценка:	+1

От:	adontz	http://adontz.wordpress.com/
Дата:	13.02.11 15:54
Оценка:	47 (1)

От:	VladD2	www.nemerle.org
Дата:	10.02.11 19:43
Оценка:	2 (1)

От:	_Eter_	http://mnazarov.ru
Дата:	10.02.11 13:32
Оценка:

От:	sergey_shandar	http://getboost.codeplex.com/
Дата:	10.02.11 15:37
Оценка: