Поговорив со знакомыми девушками из контакта, пришёл к выводу, что в распространении вирусов чаще всего виновата прекрасная половина человечества.
Как говорят девушки, когда от подруги приходит какая-нибудь ссылка, у них и мыслей не возникает, что это может быть подстава. А если ссылка не открывается, кидают другим попробовать, вдруг заработает.
Так и получается, от одной девушки её подругам и пошло поехало)
Я считаю, что программисты должны обладать знаниями английского языка, хотя бы на уровне чтения документации и понимания интерфейса среды разработки.
Почему ситуация с локализацией vs мне не нравится, приведу пример:
У меня есть приятель, ему лет 25, немного повёрнут, с языками у него проблема. Захотел как-то он изучать фотошоп, купил несколько книг, поставил себе софт + русификатор. Потом он мне рассказывал, как 30 минут искал в фотошопе фильтр под названием Sharpen (резкость). И такое происходило практически с любым пунктом меню, потому что книга была ориентирована на анг интерфейс, а фотошоп у него был русский.
Вернёмся к теме локализации.
Скоро может появиться появление программистов, которые не знают что такое Breakpoint, Debug, Exception, возможно станут писать по-русски (как делали некоторые товарищи тут). Ничего хорошего из этого не выйдет на мой взгляд.
Мешают люди, которые делают всем проблемы.
Уронит билд одна мадам, 5 минут попробует — не поднимается и забивает. Потом команда убивает драгоценное время на то, чтобы исправить косяки этой мадам.
Я с вами не согласен по поводу невозможности бытового использования в сферах игр, фильмов и сёрфинга.
Сам недавно купил 22" wide на TN матрице, графикой не увлекаюсь, работать с кодом очень удобно, углы хорошие (в отличие от ноута 5-ти летней давности), фильмы смотрю без проблем (как сидя прямо, так с других сторон и изображение практически не меняется), в играх артефактов не видно, да и с сёрфингом знаете проблем не возникает (их обычно провайдер доставляет). Что привлекает, так это цена (~10 тысяч против 20-25 на более продвинутых матрицах).
Согласен, что всё познаётся в сравнении, и если бы я проделывал те же операции скажем на PVA дисплее, возможно я бы заметил косяки и артефакты. Но что-то мне подсказывает, что это не так существенно, как скажем если сравнить мерседес и ваз. Может ауди а4 и ауди а6, чуть ниже классом, чуть похуже, но вещь хорошая.
Возможно я ошибаюсь, опять же надо попробовать и сравнить.
Согласен с Assargin, попробуйте работать с сущностями, а не с сухими полями. Правда вам, скорее всего, придётся переработать архитектуру вашего приложения.
Вы не поверите, но даже человек, работающий в солидной фирме сеньёр девелопером 3 года с технологиями .net и asp.net, умудряется путать жизненный цикл страницы на сервере (asp.net) с клиентским в браузере. А вы говорите про статик методы.
Попробую.
Например, есть BCUser — бизнес компонент для работы с пользователями.
Есть DAUser — компонент для работы с пользователями на уровне базы данных (добавление, удаление и т. д.).
Вы пишите метод в компоненте BCUser, который добавляет пользователя в систему (например по такому алгоритму):
— происходит валидация всех данных;
— происходит обращение к DAUser для сохранения пользователя в базу (у DAUser метод AddUser статичный);
— метод возвращает результат операции.
Чтобы убедиться в корректности работы метода, вам нужно его протестировать (я подразумеваю модульное тестирование). Для этого вам необходимо все вызовы сторонних компонентов заменить на обращение к мокам (Mock-объекты — тестировочный паттерн, суть которого состоит в замене объектов, используемых тестируемым кодом, на отладочные эквиваленты.) Тем самым вы изолируете вашу логику от другой.
В моём примере вам нужно заменить вызов статичного метода компонента DAUser.AddUser() на вызов метода мока. Как это обычно делается:
— используя общий интерфейс (static методы через интерфейс нельзя имплементировать);
— используя наследование (static методы нельзя перекрыть).
Получается, что мы не можем переопределить логику static метода для того, чтобы изолировать наш компонент при тестировании, и наш тест уже будет функциональным (будет использован реальный метод DAUser, который может использовать ещё множество вызовов), что может в дальнейшем породить множество проблем (например, тест будет падать, если мы в цепочке вызовов изменим логику, либо будет отсутствовать доступ к бд на этапе прогона тестов).
Как говорят девушки, когда от подруги приходит какая-нибудь ссылка, у них и мыслей не возникает, что это может быть подстава. А если ссылка не открывается, кидают другим попробовать, вдруг заработает.
Так и получается, от одной девушки её подругам и пошло поехало)
Про локализованный мсдн я ничего против не имею. Свои аргументы приводил против локализации студии.
Почему ситуация с локализацией vs мне не нравится, приведу пример:
У меня есть приятель, ему лет 25, немного повёрнут, с языками у него проблема. Захотел как-то он изучать фотошоп, купил несколько книг, поставил себе софт + русификатор. Потом он мне рассказывал, как 30 минут искал в фотошопе фильтр под названием Sharpen (резкость). И такое происходило практически с любым пунктом меню, потому что книга была ориентирована на анг интерфейс, а фотошоп у него был русский.
Вернёмся к теме локализации.
Скоро может появиться появление программистов, которые не знают что такое Breakpoint, Debug, Exception, возможно станут писать по-русски (как делали некоторые товарищи тут). Ничего хорошего из этого не выйдет на мой взгляд.
Уронит билд одна мадам, 5 минут попробует — не поднимается и забивает. Потом команда убивает драгоценное время на то, чтобы исправить косяки этой мадам.
Сам недавно купил 22" wide на TN матрице, графикой не увлекаюсь, работать с кодом очень удобно, углы хорошие (в отличие от ноута 5-ти летней давности), фильмы смотрю без проблем (как сидя прямо, так с других сторон и изображение практически не меняется), в играх артефактов не видно, да и с сёрфингом знаете проблем не возникает (их обычно провайдер доставляет). Что привлекает, так это цена (~10 тысяч против 20-25 на более продвинутых матрицах).
Согласен, что всё познаётся в сравнении, и если бы я проделывал те же операции скажем на PVA дисплее, возможно я бы заметил косяки и артефакты. Но что-то мне подсказывает, что это не так существенно, как скажем если сравнить мерседес и ваз. Может ауди а4 и ауди а6, чуть ниже классом, чуть похуже, но вещь хорошая.
Возможно я ошибаюсь, опять же надо попробовать и сравнить.
Например, есть BCUser — бизнес компонент для работы с пользователями.
Есть DAUser — компонент для работы с пользователями на уровне базы данных (добавление, удаление и т. д.).
Вы пишите метод в компоненте BCUser, который добавляет пользователя в систему (например по такому алгоритму):
— происходит валидация всех данных;
— происходит обращение к DAUser для сохранения пользователя в базу (у DAUser метод AddUser статичный);
— метод возвращает результат операции.
Чтобы убедиться в корректности работы метода, вам нужно его протестировать (я подразумеваю модульное тестирование). Для этого вам необходимо все вызовы сторонних компонентов заменить на обращение к мокам (Mock-объекты — тестировочный паттерн, суть которого состоит в замене объектов, используемых тестируемым кодом, на отладочные эквиваленты.) Тем самым вы изолируете вашу логику от другой.
В моём примере вам нужно заменить вызов статичного метода компонента DAUser.AddUser() на вызов метода мока. Как это обычно делается:
— используя общий интерфейс (static методы через интерфейс нельзя имплементировать);
— используя наследование (static методы нельзя перекрыть).
Получается, что мы не можем переопределить логику static метода для того, чтобы изолировать наш компонент при тестировании, и наш тест уже будет функциональным (будет использован реальный метод DAUser, который может использовать ещё множество вызовов), что может в дальнейшем породить множество проблем (например, тест будет падать, если мы в цепочке вызовов изменим логику, либо будет отсутствовать доступ к бд на этапе прогона тестов).
Обычное консольное приложение:
class Program {
static void Main(string[] args) {
Test.StaticMethod();
Test test = new Test();
test.NonVirtualMethod();
test.VirtualMethod();
}
}
public class Test {
public void NonVirtualMethod() {}
public virtual void VirtualMethod() {}
public static void StaticMethod() {}
}
Компилируем и смотрим ILdasm'ом что получилось:
IL_0001: call void ConsoleApplication2.Test::StaticMethod()
IL_0006: nop
IL_0007: newobj instance void ConsoleApplication2.Test::.ctor()
IL_000c: stloc.0
IL_000d: ldloc.0
IL_000e: callvirt instance void ConsoleApplication2.Test::NonVirtualMethod()
IL_0013: nop
IL_0014: ldloc.0
IL_0015: callvirt instance void ConsoleApplication2.Test::VirtualMethod()