Спасибо!

Да. Мнение родственников о них для них очень важно.

1. Нет абсолютно не наблюдаю, но у нас еще коллектив маленький и по большому счету все равны
2. Нет. Очень ответственно к работе относятся и работают до упора. Одного пришлось отучать работать до 2 часов ночи
3. Не знаю как так сложилось, надо будет поинтересоваться. Все там признают что это плохо, но тем не менее все пишу портянки. Был бы я индусом и искал работу, то специально сделал бы сжатое и предельно конкретное резюме чтобы меня заметили
4. Еще как умеют. Но делают это предельно вежливо и корректно

Это не везение. Я всех сам отбирал и нанимал.

Тестеры кстати — это отдельная тема для разговора.

«Этот баг не наш» по моему опыту скорее особенность корпоративной культуры. И в России такого полно. Лечится довольно просто и быстро принятием соответствующих мер.

Честно говоря такой особенности не заметил. Скорее наоборот. Возможно это особенности нашей корпоративной культуры. Мои сотрудники в Индии вполне нормально к признанию своих косяков относятся. Правда после некоторого тюнинга менталитета

Я в курсе. Просто боялся, что индийцев с индейцами путать будут :-) Поэтому и употребил «индус», у нас как-то в разговорном общении оно более устоялось

К сожалению цифры по админам/сетевикам не могу прокомментировать поскольку толком не сталкивался. Сисадмин у нас местный. Уровнем сисадминов в Индии я практически сразу не впечатлился

Я не считаю это нормальным, но это общепринятая практика в Индии. Но в России я считаю резюме как правило слишком лаконичны.

Ну пару сотен человек прособеседовал точно. Правда в основном в Перми.

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

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

1) По умолчанию представления в ASP.NET MVC проектах не компилируются при сборке

2) Прочитайте пожалуйста внимательнее вводную к статье и основные причины побудившие нас создать библиотеку:
«В основном все статьи, касающиеся этой темы, предписывают использовать файлы ресурсов, при этом решение получается не гибким, громоздким, и к тому же, никак не учитывается проблема перевода скриптов и шаблонов, которые в любом современном веб-проекте составляют значительную часть»

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

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

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

Еще бы он бесплатно с этим справлялся и было бы совсем замечательно.

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

Мне кажется, что мы говорим о разных вещах. Ваши рассуждения о контроле на этапе компиляции применимы к C# коду и частично представлениям. Поясните пожалуйста что Id дают для кода на JS

Согласен, тут спорить не о чем.

Строго говоря мы предлагаем не подход, а готовую, проверенную в боевых условиях библиотеку, добавляющую средства простой и интерактивной локализации в любой ASP.NET MVC проект буквально за 5-10 минут описанными нами выше средствами.

Мы не претендуем на то, что этот подход единственно верный и правильный. Сам много лет работал и с обычными виндовыми ресурсами в DLL и с resx и еще много с чем.

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

Тут согласен полностью. От кастомного базового класса для вьюх можно спокойно отказаться ценою 5 символов (Html.). Добавим в библиотеку и дополним описание.