четверг, 9 февраля 2012 г.

Учимся читать заново


Давно понял что чтение, которому нас учили в школе и университете - это только первый шаг. С свое время увлекался скорочтением, но это не мое. 
Сейчас в Google Reade накопилось 1300 непрочитанных статей, которые хотелось бы не просто забыть, а обработать с максимальной пользой для себя. И это послужило стимулом к тому чтобы еще раз задуматься о формировании своего подхода по перевариванию этого водопада из входящей информации.
Потому недавно перечитал еще раз книгу П. Шелли "Фоточтение". Достаточно неплохая книга, хотя сам с достаточно большим скепсисом отношусь к идее читать книгу со скоростью страница за секунду.
Стоит прочитать всем, кто хочет не только улучшить свою скорость чтения, но и изменить отношение к чтению.
В книге дается несколько полезных техник по работе с материалом, и, собственно, само фоточтение только одна из этих техник.
Прочитал ее уже второй раз, только для того, чтобы напомнить себе эти техники и еще раз пересмотреть свой подход к чтению нехудожественной литературы.
Также из своей практики скажу, что немного использовал технику мандарина, пред- и пост-просмотр. Помогает намного лучше понять и уловить суть книги, но требует хорошей дисциплины. Я так и не смог перенести эти техники в разряд привычек. Возможно сейчас после обновления сделаю еще одну попытку.
Особенно полезными оказались советы по работе сразу с группой книг, когда нужно на вчера перечитать и изучить 10 книг или же насобирать материал из этих же 10 книг.

Всем доброй ночи.

пятница, 23 декабря 2011 г.

Система юнит тестов - логический компилятор вашего приложения

"A unit test is almost always written using a unit-testing framework" Roy Osherove, The Art of Unit Testing.
Всем привет.

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

Тему эту я решил поднять поскольку был на тренинге "TDD в .NET". Тренинг прошел круто, полезно и об этом можно почитать уже в нескольких отчетах. Просто спросите гугл: TDD в .NET на XPDays и он вам все расскажет.

Но что я вынес для себя и почему выбрал именно такой заголовок статьи, а не другой?
За свои скромные несколько лет работы я вынес одну банальную вещь - программисты народ ленивый, менеджерам всегда не хватает времени, поэтому хватит экспериментов, делайте как работает и не ерзайте. Соответственно, если вы хотите ввести какую-то полезную практику у себя на проекте, то в первую очередь позабодтесь об удобных инструментах для работы. Будь-то ревью кода, continuos integration, continous delivery.

Так вот возвращаясь к теме TDD. До тренинга я думал, что писать тесты до кода это сложно, непонятно, скучно. Но как оказалось наука ушла далеко вперед. Наши тренеры (Александр Белецкий @alexbeletsky и Сергей Калинетц @skalinets) показали нам связку из плагинов для студии и фреймворков для юнит тестов, которые делают разработку тестов удобной, быстрой, а их проверку и запуск настолько нативной, насколько для меня уже стала перекомпиляция проекта. Вам не нужно даже сохранять файлы с вашими изменениями в тестах и логике, для того чтобы видеть ошибки и проваленные тесты.
Потом, вечерком переваривая всю полученную информацию я и подумал о наборе юнит тестов, как об еще одном уровне компилятора - компиляторе вашей логики, который работает в фоновом режиме и сразу же проверяет насколько были правильными ваши изменения.

Инструменты следующие, очень советую посмотреть всем кто пишет на C#:
  • xUnit (NUnit) - фреймворки для юнит тестов
  • NSubstitude - фреймворм для создания моков(заглушек, пустышек для тестов)
  • Test Driven.NET - плагин, который позволяет запускать тесты под разными тулзами, и под дебагом в том числе
  • NCrunch - плагин, который в фоне запускает тесты и выдает вам красивый результат в картинках, визуально показывает покрыт ли ваш код тестами
Конечно следующим шагом стоит поднять все темы касательно написания сложных тестов, сложностей их реального применения и самое главное поддержки актуальности ваших тестов. Я этого делать не буду поскольку не имею такого опыта и могу только повторять чужие слова. Но сейчас мой проект использует .NET технологии, я обязательно попробую TDD и мы сможем похоливорить на эти темы в следующих постах.

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

Всем доброй ночи. 

вторник, 6 сентября 2011 г.

Simple Render. Интерфейс IRenderer

Продолжаем рассматривать демо с организацией простенького рендера. В прошлой заметке я рассмотрел интерфейс IEntity и его реализацию. Сегодня у нас очередь интерфейса IRenderer, который в моей схеме представляет view.
Интерфейс IRenderer достаточно прост и содержит всего один важный для нас метод render, метод в котором и будет находиться код по отрисовке той или иной сущности.
class IRenderer
{
public:
virtual ~IRenderer()
{
}
virtual void render()=0;
};
Посмотрим теперь простенькую реализацию данного интерфейса, для отрисовки объектов типа GameEntity, о которых я говорил в прошлой заметке.

class SimpleRenderer2D : public IRenderer
{
private:
GameEntity& m_Entity;
protected:
const GameEntity& getGameEntity()
{
return m_Entity;
}
public:
SimpleRenderer2D(GameEntity& entity);
virtual void render();
};
И соответственно дальше реализация метода render в данном классе:

void SimpleRenderer2D::render()
{
glPushMatrix();
glTranslatef(getGameEntity().getPosition().x, getGameEntity().getPosition().y, 0.0f);
glColor3ub(255,0,0);
glBegin(GL_QUADS);
glVertex2f(0,25);
glVertex2f(0,0);
glVertex2f(25,0);
glVertex2f(25,25);
glEnd();
glPopMatrix();
}
Теперь все выглядит, как мне кажется, просто и наглядно. Класс GameEntity не имеет никакого представления о классе SimpleRenderer2D, а значит мы можем добавлять и другие view для данного типа объектов, использовать их по своему усмотрению и это никак не отражается на нашей модели.

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