В мире Java есть такой удобный инструмент, который называется jRebel. В двух словах, он позволяет изменять код веб приложения без перезагрузки домена. То есть исправил ты значение переменной в контроллере, нажал ctrl+s и можешь уже обновлять страницу в браузере. Так же как если бы ты кодил на PHP или другом интепретируемом языке.
Прямой аналог на дот нете сделать нереально. В джаве есть некоторые механизмы, которых нет в CLR.
Однако варианты есть, и одним из них я решил воспользоваться.
Упрощённая схема такая:
1. Отслеживаем сохранение файлов с кодом
2. Програмно пересобираем проект
3. Подгружаем новую сборку в наш домен
4. Из ControllerFactory даём ссылку на уже новый контроллер, который в свою очередь обращается к новым типам
Хочу напомнить, что это прототип, так что скорее всего содержит кучу багов. Тем не менее, на некоторых достаточно крупных проектах я его уже тестировал.
Из-за непредсказуемости ошибок, некоторые части писались в стиле Debug Driven Development, так что качество кода пока хромает.
Первоначально писал на C#, но довольно быстро понял, что нервов не хватит чтобы на нём же и закончить. Поэтому я принял решение перевести всё Немерле. Это сильно упростило написание и поддержку кода, так как я смог формализовать задачу и отразить её в примитивах языка.
Здравствуйте, VladD2, Вы писали: VD>А можно об этом по подробнее?
После того, как проект пересобран, мне нужно заменить все старые типы на новые в тех местах, где они сами не заменятся. Одно из таких мест, это DI контейнер.
Алгоритм на первый взгляд достаточно простой, но вот реализация достаточно сложная.
Надо обойти весь контейнер, найти все Type'ы и инстансы из нашей сборки, сохранить локешейшены и при следующем ребилде их обновить.
Локейшен — это в простейшем случае пара (instance, fieldInfo). Но что делать, если поле находится в структуре, которая сохранена в массиве?
На с#, для того, чтобы решить эту задачу мне пришлось мастерить нефиговые такие костыли. Когда размер костылей превысил размер вменяемого кода, я понял, что надо что-то менять.
Тогда я и решил перейти на Nemerle. Теперь я при обходе, с помощью вариантов, строю абстактное дерево внутренностей контейнера. На следующем этапе я с помощью ПМ это дерево разбираю. А функцию локейшенов теперь выполняют локальные функции и partial application. Так что теперь я после ребилда прохожусь в цикле по списку функций от двух аргументов, за которыми на самом может скрываться любая логика в зависимости от того, в каком участке дерева она применяется.
Также мне пригодился макрос late, который я переделал под private, чтобы он доставал и приватные члены класса. (кстати, как правильно оформить верхушку этого макроса, я ведь там всего одну строчку изменил? сейчас там написано, что это модификация макроса late) Этот макрос позволил заменить целую библиотеку ReflectionMagic, которой я пользовался в C#.
Короче говоря, пользовался всем понемножку, оно как-то само органично вписывалось в мои требования. Или если более правильно выразить, то сократился разрыв между представлением алгоритма и его реализацией в коде.
Здравствуйте, ionoy, Вы писали:
I>Первоначально писал на C#, но довольно быстро понял, что нервов не хватит чтобы на нём же и закончить. Поэтому я принял решение перевести всё Немерле. Это сильно упростило написание и поддержку кода, так как я смог формализовать задачу и отразить её в примитивах языка.
А можно об этом по подробнее?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Ага. Я кажется потихоньку начал въезжать. Спасибо, действительно интересно. Хотя с практической точки зрения не уверен что это реально кому-то нужно — но не мне судить. Видимо нужно, раз такое появилось на свет.
ЗЫ: И ещё — спасибо за выбор bitbucket — последняя массовая шиза по поводу github, в котором ничего хорошего нет (хорошее есть, но не больше и не лучше, чем у других), — уже реально заколебала.
Здравствуйте, fddima, Вы писали: F>Ага. Я кажется потихоньку начал въезжать. Спасибо, действительно интересно. Хотя с практической точки зрения не уверен что это реально кому-то нужно — но не мне судить. Видимо нужно, раз такое появилось на свет.
У меня есть некоторые проекты, где стадия инициализации приложения занимает больше 20 секунд. То есть, если я активно правлю бэкенд, то мне после каждого изменения в коде приходится ждать почти пол минуты. В данном же случае, мне достаточно сохранить файл, переключиться на браузер и нажать F5. Как только закончится билд, я сразу получу исправленную страницу. Также не стоит забывать, что иногда очень полезно не терять сессию, кэш и прочую стейтфул информацию.
F>ЗЫ: И ещё — спасибо за выбор bitbucket — последняя массовая шиза по поводу github, в котором ничего хорошего нет (хорошее есть, но не больше и не лучше, чем у других), — уже реально заколебала.
Собственно меня привлекли бесплатные приватные репозитории. Да и к тому же, теперь там есть как Hg, так и Git.
F>Я извиняюсь, то ли чего-то не понял... Но разве ASP.NET/XSP-хосты так не работают?
Нет конечно, не так. Домен просто перезапускается.
F>ЗЫ: Лучше скажите как обновить windows-service с минимальным временем простоя, без собственных велосипедов. Собственный блэкджек будет, но позже, а пока...
Для этого надо иметь Load Balancer и 2 backend server-а.
Алгоритм простой:
1. Отключаем один из серверов от LB, таким образом запросы на него не приходят
2. Обновляем отключенный сервер
3. В LB отключаем второй сервер и включаем первый
4. Обновляем второй сервер
5. Включаем в LB второй сервер
Мы данный подход используем на практике когда надо обновить сервер вне maintenance window.
Здравствуйте, VladD2, Вы писали: VD>А можно в двух словах описать как этим делом пользоваться?
1. Создаём MVC 2/3/4 проект
2. Качаем из раздела Downloads последние бинарники
3. Добавляем в проект ссылку на EasyMVC.dll
4. В конец метода Application_Start (global.asax.cs) добавляем строку:
EasyMVC.Easy.Init();
5. Запускаем
Теперь можно зайти например в HomeController, поменять значение Message строки и рефрешнуть браузер.
Строка должна измениться при том, что домен не перегружался.
Потом ради интереса можно добавить статическую переменную в класс контроллера и использовать её в той же строке. Статические переменные копируются после ребилда, так что такой код:
static int counter = 0;
public ActionResult Index()
{
ViewBag.Message = (counter++).ToString();
return View();
}
Будет работать так, как и ожидалось.
Менять в коде приложения можно абсолютно всё. Главное, чтобы вызываемый контроллер был на месте.
Здравствуйте, ionoy, Вы писали: I>Нельзя изменять методы с лямбдами, нельзя добавлять новые члены/классы. Нельзя даже сигнатуры методов менять. I>Короче, толку от него ноль.
Короче ничего нельзя, но когда потребовалось описать зачем нужен аналог jRebel на Nemerle один человек почему то в качестве примера написал:
I>То есть исправил ты значение переменной в контроллере, нажал ctrl+s и можешь уже обновлять страницу в браузере.
Так вот для случая изменения значения переменной Edit and Continue гораздо круче.
В частности можно даже не прерывать отладочную сессию и будет тот же стек вызовов.
Собственно, даже не потребуется обновлять страницу в браузере.
А с более глобальными изменениями, типа добавления новых членов, новых классов, изменения сигнатур методов и так неплохо справляется механизм ASP.NET
Поменял страницу, Ctrl+S, ну может быть еще Ctrl+B, вот уже и новая функциональность.
Вообще сама по себе странная идея брать что-то с заведомо устаревшей платформы Java и переносить её на обогнавшую её на годы платформу .NET.
Re[7]: Прототип аналога jRebel на Немерле
От:
Аноним
Дата:
01.05.12 20:47
Оценка:
Здравствуйте, ionoy, Вы писали:
I>Вполне корректно. На практике он никому не нужен.
StackOverflow [jRebel] — 31 questions tagged
StackOverflow [Edit-and-continue] — 24 questions tagged
На сайте из вашей подписи.
I>Это не самый часто встречающийся сценарий.
Первый сценарий который пришел вам в голову.
I>Уместны.
Разве что от зависти. В Java такой штуки нет, про C++ уж молчу, может в каком Javascript или Ruby и можно реализовать, но без преимуществ статики.
I>Потому что в том виде, в котором эта фича реализована она никому не нужна.
Нужна очень многим, даже в текущем виде.
I>Ей практически невозможно пользоваться.
Если про нее не знать.
I>Где же тут Killer, если она ничего кроме примитивных вещёй не умеет.
Они же самые распространенные.
I>Дай мне пример, где это работает. Если честно я себе не представляю, как это можно сделать без жёсткого геморроя.
Допустим при загрузке Веб-приложения, оно при инициализации тупо создает БД уничтожая предыдущую версию, и наполняет её какими-то данными.
Естественно, процесс не очень быстрый. А база допустим строится по метаданным в коде на C#.
Самый примитивный способ переменная в конфиге и не пересоздавать каждый раз базу, тогда собственно запуск будет гораздо быстрее. Можно разнести на два приложения и в MSBuild настроить чтобы при изменениях в метаданных запускалось создание данных. В IIS можно вести развертывание в разные пули приложений.
I>Зачем веб приложению строгое имя?
Ну вы еще спросите зачем вообще нужны строгие имена.
Вот почему-то уверен, что на сайте микрософта веб-приложения имеют соответствующую подпись.
I>Я не понимаю, что ты пытаешься здесь доказать.
Не очень понимаю, чего вы не понимаете. Здесь форум, здесь могут высказывать критические замечания.
I>Ну не будет это никому интересно и ладно, что поделать. Жалко будет потраченого времени, но не более того.
Уже кой-кому интересно, судя хотя бы по этой ветке. Не мне, сразу говорю.
I>Дэвид Еббо, кстати, сказал что ему проект интересен и он будет следить.
А я вот высказал критические замечания. На форумах, кто-то похвалит, кто-то поругает, так и живем.
Здравствуйте, Аноним, Вы писали: А>StackOverflow jRebel — 238 search results А>StackOverflow "edit and continue" — 270 search results
Правильно, потому что "edit and continue" больше создаёт проблем, чем решает. Вот люди и спрашивают, как их обойти.
I>>Это не самый часто встречающийся сценарий. А>Первый сценарий который пришел вам в голову.
Да, но только я слабо представляю, какие переменные нужно менять в экшенах.
Зато представляю, что часто приходится добавлять параметры, поля во viewmodel, изменять запрос к базе.
А>Разве что от зависти. В Java такой штуки нет, про C++ уж молчу, может в каком Javascript или Ruby и можно реализовать, но без преимуществ статики.
Потому что в Джава есть круче, там можно целиком класс загрузить. Вот это уже полезная фишка, в отличае от...
И что нужно реализовывать в Javascripte или Ruby? Изменение кода во время дебага?
I>>Потому что в том виде, в котором эта фича реализована она никому не нужна. А>Нужна очень многим, даже в текущем виде.
Я встречал только людей, которые отключали её из-за того, что она часто вылезает когда не надо.
I>>Ей практически невозможно пользоваться. А>Если про нее не знать.
В том то и дело, что она напоминает о себе, когда у тебя неожиданно срабатывает брейкпойнт. Очень бесячая штука.
I>>Где же тут Killer, если она ничего кроме примитивных вещёй не умеет. А>Они же самые распространенные.
Ну так докажи, что они самые распространённые. Приведи список того, что она умеет, и кто этим пользуется. Потом посмотрим, что из этого умеет моя библиотека.
Ну а дальше сравним
А>Допустим при загрузке Веб-приложения, оно при инициализации тупо создает БД уничтожая предыдущую версию, и наполняет её какими-то данными. А>Естественно, процесс не очень быстрый. А база допустим строится по метаданным в коде на C#. А>Самый примитивный способ переменная в конфиге и не пересоздавать каждый раз базу, тогда собственно запуск будет гораздо быстрее. Можно разнести на два приложения и в MSBuild настроить чтобы при изменениях в метаданных запускалось создание данных. В IIS можно вести развертывание в разные пули приложений.
Согласен, генерация базы данных по модели это та задача, которую можно отделить. Но она далеко не единственная и общего решения для этой проблемы не существует. Я думаю ты и сам знаешь, что таскать объекты из одного домена в другой удовольствие не из приятных.
I>>Зачем веб приложению строгое имя? А>Ну вы еще спросите зачем вообще нужны строгие имена. А>Вот почему-то уверен, что на сайте микрософта веб-приложения имеют соответствующую подпись.
Точно уверен? Может они и библиотеки только подписанные используют?
I>>Я не понимаю, что ты пытаешься здесь доказать. А>Не очень понимаю, чего вы не понимаете. Здесь форум, здесь могут высказывать критические замечания.
Критическое замечание было только одно: есть Edit and Continue. Я на это ответил, что он даже близко не сопоставим по возможностям. Единственный его плюс, это позможность менять код во время дебага, но это же и является его минусом.
I>>Дэвид Еббо, кстати, сказал что ему проект интересен и он будет следить. А>А я вот высказал критические замечания. На форумах, кто-то похвалит, кто-то поругает, так и живем.
Так ругай по делу, конструктивно. Говори, что конкретно не так сделано, что работает лучше у конкурентов (EaC). Тогда и ответы будут нормальными.
Хм. Чудеса да и только. Когда я отвечал ее не было. Зуб даю.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[13]: Прототип аналога jRebel на Немерле
От:
Аноним
Дата:
03.05.12 14:44
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Аноним, Вы писали:
VD>Да без разница какой сложности инициализирующее значение.
Ну как это без разницы, когда кто-то недавно заявлял, что значение переменной можно поменять и без Edit and Continue во время отладки.
VD>Edit and continue — это когда код меняется во время отладки. Он при этом перекомпилируется.
Вот именно.
VD>А проблему с лямбдами решить как раз довольно не сложно.
Вот-вот.
VD>Это реальное решение реальной задачи. Лишь бы он работал.
Это еще одно решение. И не самое выгодное.
VD>Не факт. В деплоймент могут включаться разные долгие операции вроде настройки БД
Тогда это уже не небольшой проект, и что мешает настройку БД и конкурирование фреймворков проводить отдельным деплойментом? Правильно ничего. Долгонастраиваемые вещи деплоим отдельно, а текущую разработку отдельно.
В качестве дополнительного плюса, получаем увеличившуюся масштабируемость проекта.
VD>А толку то? Они все взаимосвязаны и перезагрузить дин из них будет не просто.
WCF и отдельные AppDomain вообще никаких проблем.
VD>ООП — это хреновая парадигма для подобных решений.
Как раз наиболее подходящая. Уже в теме появились варианты решений полностью программные, типа Orchard CMS
Интерфейсы, фасады, моки все это отлично вписывается в подобные решения.
VD>Но я смогу, например, разбить функционал по сборкам и перезагружать только одну, измененную.
Сборки в отдельные AppDomain и можно точно также перезагружать по отдельности.
А>>>>Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.
VD>Вообще-то это заметка о MC VC, а не дотнете.
VC часть Visual Studio. Потом причем тут в этом вопросе вообще дотнет, когда сравниваются IDE.
VD>А где два и три? Или один это и есть многие?
В качестве упражнения в гугле можно набрать "Edit and Continue" java, "Edit and Continue" apple и т.д.
VD>Да и где там сказано, что это киллер-фича?
Повторяю
it's the first thing
Это синоним киллер фичи. Ибо чаще всего именно их приводят в пример первыми при сравнении двух IDE.
VD>А в MS VC хотелось бы иметь кросплатформность.
В IDE Visual C, конечно есть кросплатформенность.
Не особо трудно из нее компилить хоть под ARM, да и отлаживать можно удаленно.
Или надо чтобы Visual C, запускалось под Wine?
Я извиняюсь, то ли чего-то не понял... Но разве ASP.NET/XSP-хосты так не работают?
ЗЫ: Лучше скажите как обновить windows-service с минимальным временем простоя, без собственных велосипедов. Собственный блэкджек будет, но позже, а пока...
И ещё — по поводу оформления проекта — readme.txt — просто отвратителен — попытайтесь вменяемо описать для чего этот проект предназначен, что делает и как его использует — не нужно очень много текста, но сейчас, если зайти на страницу проекта — даже неясно для чего эта штукенция! Это нехорошо.
Здравствуйте, fddima, Вы писали: F>И ещё — по поводу оформления проекта — readme.txt — просто отвратителен — попытайтесь вменяемо описать для чего этот проект предназначен, что делает и как его использует — не нужно очень много текста, но сейчас, если зайти на страницу проекта — даже неясно для чего эта штукенция! Это нехорошо.
Да, тут должен извиниться. Только вчера репозиторий сделал публичным, и пока он не предназначен для простых пользователей. В readme сейчас только самое необходимое -- как приладить EasyMVC к своему проекту.
Здравствуйте, ionoy, Вы писали:
I>кстати, как правильно оформить верхушку этого макроса, я ведь там всего одну строчку изменил?
По уму нужно добавить дополнительный параметр с дефолтным значением, так чтобы по умолчанию было старое поведение, но когда нужно можно было бы указать, что нужен приватный член. Ну, и предложить пул-реквест.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, fddima, Вы писали:
F>ЗЫ: И ещё — спасибо за выбор bitbucket — последняя массовая шиза по поводу github,
Какая разница какой сорс-контрол?
F>в котором ничего хорошего нет (хорошее есть, но не больше и не лучше, чем у других), — уже реально заколебала.
В нем есть подстветка немерла
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re: Прототип аналога jRebel на Немерле
От:
Аноним
Дата:
01.05.12 13:40
Оценка:
Здравствуйте, ionoy, Вы писали:
I>В мире Java есть такой удобный инструмент, который называется jRebel.
В мире .NET есть такая штука как Edit and Continue.
Здравствуйте, Аноним, Вы писали: А>В мире .NET есть такая штука как Edit and Continue.
Спасибо, кэп.
Edit and Continue — очень ограниченная штука. Нельзя изменять методы с лямбдами, нельзя добавлять новые члены/классы. Нельзя даже сигнатуры методов менять.
Короче, толку от него ноль.
Здравствуйте, Аноним, Вы писали:
А>Короче ничего нельзя, но когда потребовалось описать зачем нужен аналог jRebel на Nemerle один человек почему то в качестве примера написал: I>>То есть исправил ты значение переменной в контроллере, нажал ctrl+s и можешь уже обновлять страницу в браузере. А>
Это был самый простой пример, который я мог привести, чтобы показать функциональность. Зачем цепляться за это?
А>Так вот для случая изменения значения переменной Edit and Continue гораздо круче. А>В частности можно даже не прерывать отладочную сессию и будет тот же стек вызовов. А>Собственно, даже не потребуется обновлять страницу в браузере.
Он "круче" только тем, что можно во время дебага менять код. Только в реальности это никем никогда не используется.
Зато замыкания используются очень часто.
А>А с более глобальными изменениями, типа добавления новых членов, новых классов, изменения сигнатур методов и так неплохо справляется механизм ASP.NET
Как это он справляется в MVC, подскажешь?
А>Поменял страницу, Ctrl+S, ну может быть еще Ctrl+B, вот уже и новая функциональность.
Если мы говорим про Web Application, то не "ну может быть ещё Ctrl+B", а обязательно Ctrl+Shift+B. На лету компилируются только представления.
А>Вообще сама по себе странная идея брать что-то с заведомо устаревшей платформы Java и переносить её на обогнавшую её на годы платформу .NET.
Я ничего не переносил с Java, я только взял идею. Увидел как знакомые радуются jRebel и решил, что нечто подобное могло бы быть и на .NET
Здравствуйте, ionoy, Вы писали:
I>Это был самый простой пример, который я мог привести, чтобы показать функциональность. Зачем цепляться за это?
Что значит цепляться? Очевидно, что это был самый распространенный пример, который прежде всего приходит в голову.
Поэтому заявлять что толку от Edit and Continue ноль, некорректно.
Где же ноль, когда он успешно справляется с самым часто встречающимся случаем?
I>Он "круче" только тем, что можно во время дебага менять код.
Это, мягко говоря, не слабо, кавычки заведомо не уместны.
Вообще сомнительно что подобная возможность есть в каких-либо других более-менее распространенных языков программирования. Симулу и Модулу в расчет не берем.
I>Зато замыкания используются очень часто.
Да, это большой недостаток Edit and Continue.
Впрочем и без поддержки замыканий, это одна из Killer возможностей .NET.
I>Как это он справляется в MVC, подскажешь?
MVC заточен на более длительный цикл разработки с активным использованием Юнит тестирования.
Подход с подгрузкой в рантайме измененных классов в домен в нём слабо уместен, так как вполне вероятно, что новые классы, новые методы, просто не пройдут юнит тесты, или они для них вообще еще не будут написаны.
I>а обязательно Ctrl+Shift+B. На лету компилируются только представления.
Ну собственно я и говорю, нажать дополнительно пару кнопок.
Если же имеет место какая-то длительная инициализация, то её уместно вынести в отдельный домен сервис и так далее, а часто редактируемую часть приложения в другой.
I>Увидел как знакомые радуются jRebel и решил, что нечто подобное могло бы быть и на .NET
Насколько я понимаю, на java jRebel сделано с глубоким внедрением в JDK.
У вас же фактически повторение идеи с ASP.NET, ну чуть более оптимизированное, думаю выигрышь достигается только на каких-то супер огромных сборках или на слабом железе. И кстати сомневаюсь, что решение совместимо например со строгими именами сборки.
Здравствуйте, Аноним, Вы писали: А>Поэтому заявлять что толку от Edit and Continue ноль, некорректно.
Вполне корректно. На практике он никому не нужен.
А>Где же ноль, когда он успешно справляется с самым часто встречающимся случаем?
Это не самый часто встречающийся сценарий.
I>>Он "круче" только тем, что можно во время дебага менять код. А>Это, мягко говоря, не слабо, кавычки заведомо не уместны.
Уместны.
А>Вообще сомнительно что подобная возможность есть в каких-либо других более-менее распространенных языков программирования. Симулу и Модулу в расчет не берем.
Потому что в том виде, в котором эта фича реализована она никому не нужна. Ей практически невозможно пользоваться.
I>>Зато замыкания используются очень часто. А>Да, это большой недостаток Edit and Continue. А>Впрочем и без поддержки замыканий, это одна из Killer возможностей .NET.
Где же тут Killer, если она ничего кроме примитивных вещёй не умеет.
I>>Как это он справляется в MVC, подскажешь? А>MVC заточен на более длительный цикл разработки с активным использованием Юнит тестирования.
Он только даёт возможность легко тестировать, но не заставляет.
А>Подход с подгрузкой в рантайме измененных классов в домен в нём слабо уместен, так как вполне вероятно, что новые классы, новые методы, просто не пройдут юнит тесты, или они для них вообще еще не будут написаны.
Не все пишут Tests First.
I>>а обязательно Ctrl+Shift+B. На лету компилируются только представления. А>Если же имеет место какая-то длительная инициализация, то её уместно вынести в отдельный домен сервис и так далее, а часто редактируемую часть приложения в другой.
Дай мне пример, где это работает. Если честно я себе не представляю, как это можно сделать без жёсткого геморроя.
I>>Увидел как знакомые радуются jRebel и решил, что нечто подобное могло бы быть и на .NET А>Насколько я понимаю, на java jRebel сделано с глубоким внедрением в JDK. А>У вас же фактически повторение идеи с ASP.NET, ну чуть более оптимизированное, думаю выигрышь достигается только на каких-то супер огромных сборках или на слабом железе. И кстати сомневаюсь, что решение совместимо например со строгими именами сборки.
Зачем веб приложению строгое имя?
---
Я не понимаю, что ты пытаешься здесь доказать. Ну не будет это никому интересно и ладно, что поделать. Жалко будет потраченого времени, но не более того.
Дэвид Еббо, кстати, сказал что ему проект интересен и он будет следить.
Здравствуйте, <Аноним>, Вы писали:
А>Разве что от зависти. В Java такой штуки нет, про C++ уж молчу,
Edit and continue был еще в VC++6.
В VC++7 я его использовал на практике.
I>>Потому что в том виде, в котором эта фича реализована она никому не нужна. А>Нужна очень многим, даже в текущем виде.
В текущем виде она действительно малополезна.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, VladD2, Вы писали:
F>>в котором ничего хорошего нет (хорошее есть, но не больше и не лучше, чем у других), — уже реально заколебала.
VD>В нем есть подстветка немерла
На битбакете тоже есть ) Имхо, там те же пигменты, что и на гитхабе.
Re[9]: Прототип аналога jRebel на Немерле
От:
Аноним
Дата:
02.05.12 13:13
Оценка:
Здравствуйте, ionoy, Вы писали:
А>>StackOverflow jRebel — 238 search results А>>StackOverflow "edit and continue" — 270 search results I>Правильно, потому что "edit and continue" больше создаёт проблем, чем решает.
Это такие глобальные выводы сделаны что количество тем на 15% больше?
А почему тэги, тогда обойдены, там же противоположная ситуация?
I>Да, но только я слабо представляю, какие переменные нужно менять в экшенах. I>Зато представляю, что часто приходится добавлять параметры, поля во viewmodel, изменять запрос к базе.
Например запрос к базе в переменной, взяли и поменяли.
I>Потому что в Джава есть круче, там можно целиком класс загрузить.
Чем же это круче? Наоборот заведомо слабее.
Подменять реализацию класса во время работы, это вообще пустяк, не сложно делать даже чисто программным способом, вообще без поддержки рантайма. Интерфейсы, фасады, фабрики там и так далее.
I>И что нужно реализовывать в Javascripte или Ruby? Изменение кода во время дебага?
Не обязательно нужно, а сравнительно нетрудно сделать по сравнению с Java, в этом была мысль.
I>Я встречал только людей, которые отключали её из-за того, что она часто вылезает когда не надо.
Тем не менее она заметно поднимает производительность труда программиста.
Неоднократно встречал просьбы в интернете сделать поддержку для GDB, GCC, Java и т.д.
I>В том то и дело, что она напоминает о себе, когда у тебя неожиданно срабатывает брейкпойнт. Очень бесячая штука.
I>Ну так докажи, что они самые распространённые.
Уже доказал пару раз. Повторяю — это первое что пришло вам в голову когда вы писали зачем нужен аналог jRebel на Nemerle.
I>Я думаю ты и сам знаешь, что таскать объекты из одного домена в другой удовольствие не из приятных.
Вот с этим категорически не согласен. Веб-сервисы и сама WCF давно это дыру закрыли, и все сделали очень прозрачным. Есть в Visual Studio соответствующие визарды, да и многое вообще декларативно.
То есть нетрудно сравнительно быстро разделить приложение физически на две части, если оно и так уже логически разделено. А отдельные части потом можно запускать хоть в разных доменах, хоть на разных машинах, меняются только конфиги.
I>Точно уверен? Может они и библиотеки только подписанные используют?
Думаю так и есть, это одна из дополнительных защит, зачем её избегать, особенно когда за работу платят приличные деньги. Не удивлюсь если у них просто политика безопасности на серверах, единая на всех, запускаются только подписанные приложения, да еще и из белого списка. То есть подписывать не подписывать, решают не разработчики, а админы серверов.
I>Критическое замечание было только одно: есть Edit and Continue. Я на это ответил, что он даже близко не сопоставим по возможностям.
С этим согласен, даже близко не сопоставим, а гораздо круче.
Впрочем мы начинаем ходить по кругу.
I>Так ругай по делу, конструктивно.
Я и выступаю максимально конструктивно, даже приводил статистику.
Короче, еще разок приведу свое мнение:
jRebel на платформе .NET не нужен.
Для изменения переменных во время отладки используйте Edit and Continue.
Для ускорения развертывания приложения, разбивайте его на отдельные части, это поможет и в дальнейшем для масштабирования приложения, эти отдельные части можно будет развертывать на отдельных машинах. А jRebel условно поможет только в разработке.
Здравствуйте, Ziaw, Вы писали:
VD>>В нем есть подстветка немерла
Z>На битбакете тоже есть ) Имхо, там те же пигменты, что и на гитхабе.
Ты бы на ссылку, что в тематическом сообщении, нажал бы для начала. Я как-то там не заметил подсветки.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[9]: Прототип аналога jRebel на Немерле
От:
Аноним
Дата:
02.05.12 13:29
Оценка:
Здравствуйте, WolfHound, Вы писали:
WH>Edit and continue был еще в VC++6. WH>В VC++7 я его использовал на практике.
Я имел ввиду Managed C++.
I>>>Потому что в том виде, в котором эта фича реализована она никому не нужна. А>>Нужна очень многим, даже в текущем виде. WH>В текущем виде она действительно малополезна.
I> Не нужна A> Нужна W> Малополезна
Для изменения значения переменной во время отладки вполне себе полезна.
Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.
Здравствуйте, Аноним, Вы писали:
А>Короче, еще разок приведу свое мнение: А>jRebel на платформе .NET не нужен. А>Для изменения переменных во время отладки используйте Edit and Continue. А>Для ускорения развертывания приложения, разбивайте его на отдельные части, это поможет и в дальнейшем для масштабирования приложения, эти отдельные части можно будет развертывать на отдельных машинах. А jRebel условно поможет только в разработке.
Это и есть инструмент облегчающий разработку, на развёртывание он никак не повлияет.
Короче мнение я твоё понял, предлагаю на этом спор окончить.
Здравствуйте, Аноним, Вы писали:
А>Для изменения значения переменной во время отладки вполне себе полезна.
Изменить значение переменной в отладчике можно и без всяких эдтиов энд континью (с) маркетологи. Оно на то и значение.
Edit and continue полезен когда нужно что-то поправить по мелочи и пойти дальше. Фича приятная не спорю. Но так же глупо спорить и стем, что полезна она очень редко. А с появлением linq-а она становится и вовсе бесполезной, так как замыкания теперь просто везде.
В общем, было бы конечно просто супер, если статически типизированные компилируемые программы можно было бы менять как срипты. Но пока что это не так. А стало быть аналог jRebel не помешает.
Интерактивность разработки — это довольно важный аспект. На мой взгляд главный недостаток немерла — низкая скорость компиляции.
А>Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.
Если многими, то тебе не составит труда дать ссылок на подобные мнения?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, ionoy, Вы писали:
I>В мире Java есть такой удобный инструмент, который называется jRebel...
А можно в двух словах описать как этим делом пользоваться?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Re[11]: Прототип аналога jRebel на Немерле
От:
Аноним
Дата:
02.05.12 15:22
Оценка:
Здравствуйте, VladD2, Вы писали:
VD>Изменить значение переменной в отладчике можно и без всяких эдтиов энд континью (с) маркетологи. Оно на то и значение.
Под значением имелось ввиду естественно сравнительно сложное выражение, а не литерал или простое присваивание другой переменной.
VD>А с появлением linq-а она становится и вовсе бесполезной, так как замыкания теперь просто везде.
Пока микрософт заявляет, что потребуется серьезная переработка для API дебаггера.
Но будем ждать.
VD>А стало быть аналог jRebel не помешает.
Это подход не с той стороны. И вообще в каком-то смысле самопротиворечив.
Если у вас небольшой проект, то деплоймент быстрый и проблемы нет.
Если же проект большой, то лучше его не делать в виде монолита, а разбить на части, сведя к первому случаю.
VD>На мой взгляд главный недостаток немерла — низкая скорость компиляции.
А это не про скорость компиляции, а про скорость развертывания — деплоймент.
Компиляция никуда не девается.
А>>Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.
VD>Если многими, то тебе не составит труда дать ссылок на подобные мнения? http://stackoverflow.com/questions/4303599/edit-and-continue-on-gdb
Вот цитата по ссылке
my experience says it's the first thing MSVC users mention when asked "why not switch to Eclipse and gcc/gdb"
Здравствуйте, Tom, Вы писали:
Tom>Для этого надо иметь Load Balancer и 2 backend server-а.
Спасибо. К такому решению я и сам пришел, но пока что работа вне кластера.
Здравствуйте, ionoy, Вы писали:
I>В мире Java есть такой удобный инструмент, который называется jRebel. В двух словах, он позволяет изменять код веб приложения без перезагрузки домена. То есть исправил ты значение переменной в контроллере, нажал ctrl+s и можешь уже обновлять страницу в браузере. Так же как если бы ты кодил на PHP или другом интепретируемом языке.
То что вы реализовали есть в Orchard CMS, но без перестроения контейнера. Решение основано на Autofac IoC, конкретно с помощью вложенных Scope.
Объекты в контейнере по Scope делятся на три типа: корневой, модульный, все остальные (создаваемые на каждый запрос, на каждый inject).
Корневые объекты загружаются в контейнер при старте приложения и не выгружаются до конца работы. Модульные объекты загружаются при старте приложения, при включении/отключении плагина и при перекомпиляции модуля. Контроллеры относятся к модульным объектам. Когда происходит перекомпиляция Scope уровня Module уничтожается и создается заново, то же самое происходит при загрузке/выгрузке плагинов. Такое подход избавляет от заказа солнца вручную
Здравствуйте, Аноним, Вы писали:
VD>>Изменить значение переменной в отладчике можно и без всяких эдтиов энд континью (с) маркетологи. Оно на то и значение. А>Под значением имелось ввиду естественно сравнительно сложное выражение, а не литерал или простое присваивание другой переменной.
Да без разница какой сложности инициализирующее значение. Это все равно не связано с Edit and continue.
Edit and continue — это когда код меняется во время отладки. Он при этом перекомпилируется.
VD>>А с появлением linq-а она становится и вовсе бесполезной, так как замыкания теперь просто везде. А>Пока микрософт заявляет, что потребуется серьезная переработка для API дебаггера. А>Но будем ждать.
До они могут что угодно заявлять. Весь их студийный API уже давно пора переписать целиком.
Полностью проблему им не решить без внесения изменений в дотнет. Основная проблема там — это подмена типов. Типы в дотнете — это статические конструкции на которые много чего завязано.
Так что гибкости динамически типизированных языков вряд ли в ближашие лет 10 удастся добиться.
А проблему с лямбдами решить как раз довольно не сложно. Думаю они ее решат когда перейдут на менеджед-компилятор. А это по скромным прикидкам будет не раньше чем через пару лет.
VD>>А стало быть аналог jRebel не помешает. А>Это подход не с той стороны.
Это реальное решение реальной задачи. Лишь бы он работал.
А остальное — бессмысленное сотрясение воздуха.
А>И вообще в каком-то смысле самопротиворечив. А>Если у вас небольшой проект, то деплоймент быстрый и проблемы нет.
Не факт. В деплоймент могут включаться разные долгие операции вроде настройки БД, конкурирование фрэймворков и т.п.
А>Если же проект большой, то лучше его не делать в виде монолита, а разбить на части, сведя к первому случаю.
А толку то? Они все взаимосвязаны и перезагрузить дин из них будет не просто. ООП — это хреновая парадигма для подобных решений. По сему возможность перезагрузить одну сборку один фиг очень полезна.
VD>>На мой взгляд главный недостаток немерла — низкая скорость компиляции. А>А это не про скорость компиляции, а про скорость развертывания — деплоймент. А>Компиляция никуда не девается.
Но я смогу, например, разбить функционал по сборкам и перезагружать только одну, измененную.
А>>>Конечно, было бы хорошо иметь меньше ограничений, но и в текущем виде многими считается одним из существенных преимуществ Visual Studio над другими IDE.
VD>>Если многими, то тебе не составит труда дать ссылок на подобные мнения? А>http://stackoverflow.com/questions/4303599/edit-and-continue-on-gdb А>Вот цитата по ссылке А>
А>my experience says it's the first thing MSVC users mention when asked "why not switch to Eclipse and gcc/gdb"
Вообще-то это заметка о MC VC, а не дотнете. Ну, да ладно. Раз! А где два и три? Или один это и есть многие?
Да и где там сказано, что это киллер-фича? Да, мужик хочет такую же на линуксе. С этим не поспоришь. А в MS VC хотелось бы иметь кросплатформность. И что?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, achmed, Вы писали: A>То что вы реализовали есть в Orchard CMS, но без перестроения контейнера. Решение основано на Autofac IoC, конкретно с помощью вложенных Scope. A>Объекты в контейнере по Scope делятся на три типа: корневой, модульный, все остальные (создаваемые на каждый запрос, на каждый inject). A>Корневые объекты загружаются в контейнер при старте приложения и не выгружаются до конца работы. Модульные объекты загружаются при старте приложения, при включении/отключении плагина и при перекомпиляции модуля. Контроллеры относятся к модульным объектам. Когда происходит перекомпиляция Scope уровня Module уничтожается и создается заново, то же самое происходит при загрузке/выгрузке плагинов. Такое подход избавляет от заказа солнца вручную
Спасибо, не знал об этом.
Почитал об архитектуре этого решения — сделано достаточно интересно. У меня, кстати, первоначально была такая же идея, сделать настоящий фреймворк с модулями и прочим.
Однако тут есть ряд недостатков:
1. Изменения подгружаются только внутри модулей, и то, видимо, не всегда: (In some cases, these changes require an ASP.NET AppDomain restart (e.g. a new version of a module assembly needs to be loaded). Orchard detects these situations and forces an ASP.NET AppDomain restart.)
2. Пользователя привязывают к одному контейнеру и конкретной архитектуре. Текущий проект на это решение не переведёшь.
3. Решение не общее, а следственно не подходит для любого сайта. Думаю, что там сейчас вообще проблемно отделить всю эту инфраструктуру от Orchard, хотя это и не самое главное.
4. Как минимум это решение требует больше трудозатрат со стороны программиста (сравни с добавлением одной строчки в global.asax.cs)
Мой же проект умеет всё что и этот, но при этом лишён его недостатков:
1. Не привязан к конкретному IoC контейнеру
2. Не привязан к архитектуре
3. Изменять в проекте можно абсолютно всё, главное чтобы он потом скомпилировался
4. И что, по-моему, самое главное — он абсолютно прозрачен для программиста. О нём не нужно думать, его не видно (если специально не следить), он просто работает сам по себе.
Нисколько не хочу принизить достижение парней из команды Orchard, там видимо реально крутые парни сидят. Думаю, конкретно для CMS их механизм подходит даже лучше, так как вносит в проект логическую структуру. Но тем не менее эта штука очень специфична и для общего решения имхо не подходит.
Здравствуйте, ionoy, Вы писали:
I>Спасибо, не знал об этом.
I>Почитал об архитектуре этого решения — сделано достаточно интересно. У меня, кстати, первоначально была такая же идея, сделать настоящий фреймворк с модулями и прочим.
I>Однако тут есть ряд недостатков: I>1. Изменения подгружаются только внутри модулей, и то, видимо, не всегда: (In some cases, these changes require an ASP.NET AppDomain restart (e.g. a new version of a module assembly needs to be loaded). Orchard detects these situations and forces an ASP.NET AppDomain restart.)
это случай когда устанавливается новая версия плагина
I>2. Пользователя привязывают к одному контейнеру и конкретной архитектуре. Текущий проект на это решение не переведёшь.
Это да, на орчард не так то просто перевести готовое решение
I>3. Решение не общее, а следственно не подходит для любого сайта. Думаю, что там сейчас вообще проблемно отделить всю эту инфраструктуру от Orchard, хотя это и не самое главное. I>4. Как минимум это решение требует больше трудозатрат со стороны программиста (сравни с добавлением одной строчки в global.asax.cs)
ну что сказать, здОрово
I>Мой же проект умеет всё что и этот, но при этом лишён его недостатков: I>1. Не привязан к конкретному IoC контейнеру I>2. Не привязан к архитектуре I>3. Изменять в проекте можно абсолютно всё, главное чтобы он потом скомпилировался I>4. И что, по-моему, самое главное — он абсолютно прозрачен для программиста. О нём не нужно думать, его не видно (если специально не следить), он просто работает сам по себе.
I>Нисколько не хочу принизить достижение парней из команды Orchard, там видимо реально крутые парни сидят. Думаю, конкретно для CMS их механизм подходит даже лучше, так как вносит в проект логическую структуру.
парни очень крутые работая с Orchard много нового узнал
I>Но тем не менее эта штука очень специфична и для общего решения имхо не подходит.
Здравствуйте, Аноним, Вы писали:
>> Тем не менее она заметно поднимает производительность труда программиста. >> Неоднократно встречал просьбы в интернете сделать поддержку для GDB, GCC, Java и т.д.
Справедливости ради замечу, что еще в Java1.4 была таехнология HotSwap, которая делала почти то-же, что Edit&Continue, и большинство IDE ее поддерживает. Единственное отличие -- изменения применяться только при следующем вызове метода! А так, то-же самое.
