среда, 10 октября 2012 г.

WOT replays

Хочу обратить внимание всех поклонников WOT на замечательный сервис http://www.myreplays.ru

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

Регистрируетесь, вливаете свои реплеи (можно и устаревшие), получаете ссылки на ютубовские ролики на мейл.

Сюда буду свои подкладывать.

пятница, 28 сентября 2012 г.

Как эффективно сообщать об ошибках


Автор: Саймон Тэтхем
1999



Введение

Любой, кто написал программу для публичного использования, получил, по крайней мере, одно плохое сообщение об ошибке. Сообщения, которые не говорили ни о чем ("Это не работает"); сообщения, которые не имели смысла; сообщения, которые не давали достаточной информации; сообщения, которые давали неправильную информацию. Сообщения о проблемах, которые оборачивались ошибками пользователя; сообщения о проблемах, которые оборачивались дефектом в чьей-то другой программе; сообщения о проблемах, которые оборачивались сбоями сети.

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

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

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

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

История одного байта


Автор: Dmitry Galuscenko
08 мая 2001


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

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

Мы программируем чипы однокристаллки, грубо говоря, это когда весь комп в одном кристалле. Програмная память и память данных разделены и не взаимодействуют между собой. Программа не может быть запущена в оперативке. Глубина програмного стека ограничена. Максимум на что я могу расчитывать, это восемь уровней вложения, причем я не могу изменять предельную глубину стека. О, вы не подумайте чего! У меня бездна ресурсов. Оперативки аж 128 байт! Это на все про все. Переменные, там то да се.. 

Представили, да? С програмной памятью тоже неплохо. Аж восемь килобайт. И пользоваться ей совсем несложно. Сначала нужно программно врубить нужный банк памяти, запустить в нем нужную процедуру, а по выходе из нее не забыть вернуться где был. Да еще надо иметь в виду, что в пределах банка я могу пермещаться только джампами и вызовами процедур, а переходы по условиям возможны только в пределах одной страницы, т.е. 256 байт. Это значит, если я сравниваю два байта и надо ветвиться, но если метка не находится в пределах 256 байт, то это письмо на деревню дедушке, причем компилятор только в половине случаев предупредит, мол широко шагаешь парень, штаны бы поберег. И это только цветочки! Ягодки я вам счас выложу, чтоб вы ими в полной мере могли насладиться.

Биг Маки против "обнаженного шеф-повара"


Автор: Джоэл Сполски

Переводчик: Сергей Калмаков 
Редактор: Дмитрий Майоров 
18 января 2001


В английском оригинале статья называется Big Macs vs. The Naked Chef


Загадка: почему так происходит, что некоторые из крупнейших консалтинговых компаний в мире по информационным технологиям делают самую плохую работу?

Почему так случается, что "крутые" новые консалтинговые компании начинают с череды впечатляющих успехов, метеорного взлета, и быстро деградируют до посредственных?

Я размышлял об этом, и думал о том, как Fog Creek Software (моя компания) должна расти. И лучшие уроки, которые я смог найти, пришли из Макдоналдс. Да-да, я имею в виду эту ужасную сеть ресторанов-закусочных.

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

Другой секрет "биг маков" состоит в том, что вы можете иметь IQ (интеллектуальный коэффициент), который колеблется между "идиот"и "баран" (используя технические термины) и все равно вы будете способны выпустить "биг мак", который будет таким же заурядным, как и все другие "биг маки"в мире. Все это потому, что настоящий секретный соус Макдональдса - это его громадное руководство, описывающее в потрясающей детализации точную процедуру, которой каждый владелец франчайза должен следовать при создании "биг мака". Если "биг мак" гамбургер жарится 37 секунд в Анкоридже, Аляска, он будет жариться 37 секунд в Сингапуре - не 36 и не 38. Что бы сделать "биг мак" вы просто должны следовать этим чертовым правилам.

вторник, 25 сентября 2012 г.

Плато качества


Отрывок из книги "Programmer's Stone "

Автор: Alan G Carter and Colston Sanger
Перевод: Сергей Козлов teleman@elnet.msk.ru

7 декабря 1999 г.

Когда мысленная карта проблемной области сформирована и делаются попытки упростить ее, обычно сталкиваются с проблемой определения момента окончания работы над картой. Эта проблема возникает на каждом уровне проектирования. Сверхъестественно, но почти всегда есть глубокое решение, которое значительно проще всех остальных и очевидно минимальное. (Есть много способов это выразить, но потом этот вывод станет очевидным.) Хотя проповеди типа: "Ты узнаешь это, когда увидишь!" -- несомненная истина, но они не говорят, куда посмотреть.

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

В качестве примера возьмем код из прекрасной книги Джеффри Рихтера (Jeffrey Richter's Advanced Windows). Эта книга - полезное чтение для любого, кто пытается писать программы для Win32 API (Application Programming Interface) (поскольку иначе у вас не появится мысленная карта семантик системы).