Эрик Липперт сейчас вовсю переписывает компилятор c# на c#. Скорее всего, это серьезно намекает на то, что в 5ом FW имеет хорошие шансы появиться compiler as a service, и, как следствие, AST-трансформеры.
>> Про логгирование я чуть-чуть написал
Я имел в виду логгирование в смысле аудита, а у вас — больше трассировка. Впрочем, много общего.
>> PostSharp не умеет добавлять аспекты во время компиляции
Эм, по моим сведениям, как раз во время компиляции он и добавляет (вернее, после, как и AspectJ). А вот в рантайме — не умеет.
А вы .spect не пробовали? Интересно ваше мнение. Мне вот не понравился.
Еще распространенные аспекты — логгирование и проверки безопасности (авторизация). Это так, навскидку, только кода нет с собой.
Это интересно, но, по-моему, большинство аспектов, которые вы показали, крутится у них на сайте в баннерах или есть в прилагаемых samples. Это не так?
Вот еще что не понял: «но ни один их них не «рулит» так как PostSharp». Если говорить про post-processed AOP (instrumentation a la AspectJ), то еще понятно, но ведь существует же и run-time AOP aka «weaving», который PostSharp не умеет, а другие умеют. Имхо, такое высказывание не очень корректно без указания типа AOP-обработки.
Если подходить исключительно со стороны вопроса быстродействия: Вы думаете, что маршаллинг пары сотен байт станется медленнее, чем порождение процессов dllunreg/dllreg?
Странно, всегда думал, что манифест — это не только для .net-программ. mmm4vb6.atom5.com/ это тоже подтверждает: программа MakeMyManifest умеет сканировать vb6-проект и писать к нему манифест, чтобы тот работал без необходимости регистрации компонент.
Еще интересно, что у вас для программы на vb6 идет в комплекте утилитка на .net, для которой еще и fw нужен :) Но это уже оффтоп
Если вы обратили внимание, то я там написал не только про merge history. Так что по-моему, вы обобщаете.
Svn движется в сторону git в плане merge, это не может не радовать. Тем не менее, даже в 1.5 работает далеко не идеально. Те же tree conflicts более-менее корректно резолвятся только в 1.6.
Самый большой плюс svn по сравнению с cvs — наличие atomic commits, и гораздо более стабильный и ловкий merge, не оставляющий мусора в файле. Плюс в целом быстродействие по сети заметно выше.
Из минусов svn (или недоплюсов) по сравнению с более поздними, такими как git, bzr или hg, — rename файла, хоть и автоматизирован, но по-прежнему через «не хочу», с удалением старого и добавлением нового (история изменений теряется); история мержей не хранится, так что по невнимательности легко можно смержить одну и ту же ревизию несколько раз :)
P.S. Тот же TFS отслеживает такой неприятный момент (хотя в режиме baseless merge карты в руки — можно что угодно с чем угодно мержить)
Мне, как человеку, имеющему привычку проверять свои источники информации, глядя на «Участники:
Асхат Уразбаев, Денис Миллер, Никита Филиппов», хочется спросить — кто все эти люди? :)
Я имею в виду — где можно взглянуть на резюме и/или прочие документы, положительно характеризующие их (вас) как практических/практикующих разработчиков, а не «coach и евангелистов от Agile»?
Такой вопрос возник вот почему: на мой взгляд, управление процессами — имхо это достаточно критичная вещь, чтобы пользоваться непроверенными сведениями.
Извините, что пристал с прикладной проблемой :) Просто жизненая ситуация — в транке лежит «четверка», в одну из веток ушел «4.6» — для одного из заказчиков. Порядка полутора месяцев (пара длинных спринтов) 3+ведущий «педалят» 4.6, а затем понимают, что в 4.X хотелось бы видеть многое оттуда.
Надо переносить. А кому?
Имхо должен ведущий программимст, а он — крутит носом, потому что счас изучает фреймворк по стейт-машинам и думает, как его прикрутить.
Это пост не предполагает ответ, просто пояснял, что я имел в виду.
Это не регулярная, а разовая работа — порядка 2к коммитов в 11 ветках. Обычно все действительно проще, укладывается в 10 минут.
Но это должен же кто-то был сделать :) А художникам это — «не в жилу».
P.S. У нас не svn, а TFS; в нем есть свои проблемы мерджа, что еще более доставляет. Менять его на svn — политика компании не позволяет. Я себе поставил гейт tfs2svn, и работаю через него, но остальным художникам «технические трудности неинтересны» :)
Шутко хорошая, потому как боюсь, что результатов мы не увидим =)
Не, там в мердже не так просто, потому как выборочные коммиты переносятся. У меня ушло 2 дня только на то, чтобы понять, какие коммиты надо переносить, потому что проект очень большой, разбит на субпроекты :)
Ну так о чем это я… Собстно, о том, что это пресловутое «неинтересно» просто как серпом по… пульсу проекта :) А вот «IT-таджик» такое не скажет — он медленно, но верно доделает работу.
Видимо, тут прослеживается явная аналогия с темпераментом.
Ну хз, хз. В моей текущей команде ведущий программист — такой вот художник. И когда его просят сделать мердж из бранча в транк (ну, перенести полезные изменения в побочной ветви) он говорит «это скучно и неинтересно заниматься этой рутиной, я не хочу это делать». Как быть тут?
>> Надо просто такой ситуации не допускать.
Ситуации, когда есть в проекте баги? Вы шутите, наверное :) В любом проекте есть дефекты на любой его стадии, это еще Брукс говорил; в противном случае тестировщики ПО не нужны бы были как класс.
Беда в том, что художника сложно заставить довести задачу до конца — как только он сталкивается с трудностями, он бросает эту задачу. Вы эту особенность упорно не замечаете в статье, списывая на то, что менеджер художник сможет справиться с этим.
И менеджер-художник будет поступать точно так же, как и рядовой программист — как только его заинтересованность спадет, ему будет «покласть» на прибыль заказчика.
Я о том, что вольных художников сложно заставить фиксить эти баги, потому что это скучно, рутинно, никаких инноваций. Я сто раз слышал в такой ситуации «мне это неинтересно».
Изложите, пожалуйста, каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?
>> Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников
Нельзя.
>> Оглянитесь вокруг, в России это повсюду!
Отличный аргумент, когда нет аргументов.
>>Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать
Нет. Естественное стремление вольных художников — бросать проект, когда баги начинаются.
ИМХО: статья более пафосна и менее логична, чем первая. Извините, если чем обидел.
Эрик Липперт сейчас вовсю переписывает компилятор c# на c#. Скорее всего, это серьезно намекает на то, что в 5ом FW имеет хорошие шансы появиться compiler as a service, и, как следствие, AST-трансформеры.
Я имел в виду логгирование в смысле аудита, а у вас — больше трассировка. Впрочем, много общего.
>> PostSharp не умеет добавлять аспекты во время компиляции
Эм, по моим сведениям, как раз во время компиляции он и добавляет (вернее, после, как и AspectJ). А вот в рантайме — не умеет.
А вы .spect не пробовали? Интересно ваше мнение. Мне вот не понравился.
Это интересно, но, по-моему, большинство аспектов, которые вы показали, крутится у них на сайте в баннерах или есть в прилагаемых samples. Это не так?
Вот еще что не понял: «но ни один их них не «рулит» так как PostSharp». Если говорить про post-processed AOP (instrumentation a la AspectJ), то еще понятно, но ведь существует же и run-time AOP aka «weaving», который PostSharp не умеет, а другие умеют. Имхо, такое высказывание не очень корректно без указания типа AOP-обработки.
Еще интересно, что у вас для программы на vb6 идет в комплекте утилитка на .net, для которой еще и fw нужен :) Но это уже оффтоп
Начиная с Windows XP, можно вообще не регистрировать dll-ки, а прописать необходимые ссылки на COM-dll в файле манифеста программы.
Это наиболее быстро и по максимуму труЪ.
Svn движется в сторону git в плане merge, это не может не радовать. Тем не менее, даже в 1.5 работает далеко не идеально. Те же tree conflicts более-менее корректно резолвятся только в 1.6.
en.wikipedia.org/wiki/Comparison_of_revision_control_software
Самый большой плюс svn по сравнению с cvs — наличие atomic commits, и гораздо более стабильный и ловкий merge, не оставляющий мусора в файле. Плюс в целом быстродействие по сети заметно выше.
Из минусов svn (или недоплюсов) по сравнению с более поздними, такими как git, bzr или hg, — rename файла, хоть и автоматизирован, но по-прежнему через «не хочу», с удалением старого и добавлением нового (история изменений теряется); история мержей не хранится, так что по невнимательности легко можно смержить одну и ту же ревизию несколько раз :)
P.S. Тот же TFS отслеживает такой неприятный момент (хотя в режиме baseless merge карты в руки — можно что угодно с чем угодно мержить)
Асхат Уразбаев, Денис Миллер, Никита Филиппов», хочется спросить — кто все эти люди? :)
Я имею в виду — где можно взглянуть на резюме и/или прочие документы, положительно характеризующие их (вас) как практических/практикующих разработчиков, а не «coach и евангелистов от Agile»?
Такой вопрос возник вот почему: на мой взгляд, управление процессами — имхо это достаточно критичная вещь, чтобы пользоваться непроверенными сведениями.
Спасибо.
Надо переносить. А кому?
Имхо должен ведущий программимст, а он — крутит носом, потому что счас изучает фреймворк по стейт-машинам и думает, как его прикрутить.
Это пост не предполагает ответ, просто пояснял, что я имел в виду.
С этой фразы я понял, что у нас, видимо, разное понимание «художника». *Пошел перечитывать обе статьи*
Но это должен же кто-то был сделать :) А художникам это — «не в жилу».
P.S. У нас не svn, а TFS; в нем есть свои проблемы мерджа, что еще более доставляет. Менять его на svn — политика компании не позволяет. Я себе поставил гейт tfs2svn, и работаю через него, но остальным художникам «технические трудности неинтересны» :)
Не, там в мердже не так просто, потому как выборочные коммиты переносятся. У меня ушло 2 дня только на то, чтобы понять, какие коммиты надо переносить, потому что проект очень большой, разбит на субпроекты :)
Ну так о чем это я… Собстно, о том, что это пресловутое «неинтересно» просто как серпом по… пульсу проекта :) А вот «IT-таджик» такое не скажет — он медленно, но верно доделает работу.
Видимо, тут прослеживается явная аналогия с темпераментом.
>> Надо просто такой ситуации не допускать.
Ситуации, когда есть в проекте баги? Вы шутите, наверное :) В любом проекте есть дефекты на любой его стадии, это еще Брукс говорил; в противном случае тестировщики ПО не нужны бы были как класс.
Беда в том, что художника сложно заставить довести задачу до конца — как только он сталкивается с трудностями, он бросает эту задачу. Вы эту особенность упорно не замечаете в статье, списывая на то, что менеджер художник сможет справиться с этим.
И менеджер-художник будет поступать точно так же, как и рядовой программист — как только его заинтересованность спадет, ему будет «покласть» на прибыль заказчика.
В любом случае, за статью спасибо.
Я о том, что вольных художников сложно заставить фиксить эти баги, потому что это скучно, рутинно, никаких инноваций. Я сто раз слышал в такой ситуации «мне это неинтересно».
Изложите, пожалуйста, каким образом вменяемый менеджмент, по-вашему, поможет расправиться с багами в такой ситуации?
Пусть мой комментарий останется ИМХОм =)
>> Итак, можно поделить IT специалистов на IT-таджиков и на IT-художников
Нельзя.
>> Оглянитесь вокруг, в России это повсюду!
Отличный аргумент, когда нет аргументов.
>>Художники не любят рутины. А правка багов это рутина. Потому естественное стремление — багов не допускать
Нет. Естественное стремление вольных художников — бросать проект, когда баги начинаются.
ИМХО: статья более пафосна и менее логична, чем первая. Извините, если чем обидел.