|
|
|
November 21st, 2009
01:38 am - wanted
а у кого-нть есть котявка во временное пользование ? с целью борьбы с мышами
они перестали попадацца в мышеловку и грызут линолеум
котявка домашняя, приученная к лотку, пол неважен, нужны основательные навыки отлова особо хитрых мышей
|
November 20th, 2009
November 14th, 2009
01:35 am
сидим за решёткой в темнице сырой (с) :о))
|
01:33 am
коты ушли с работы и пока тренируюцца дома
|
November 11th, 2009
01:15 am
если тебе кажется, что все хорошо, то последний косяк был лишним (с)
|
November 10th, 2009
11:02 pm
вот что можно сделать с обыкновенным тыквом в домашних условиях :
http://users.livejournal.com/_mju_/6411.htm
|
November 6th, 2009
03:38 pm
скайп у кого-нть имеецца ? :о))
комменты на всякий случай заскринены
|
01:28 pm
не пишу комменты, если включена капча
принципиально :о))
|
01:19 pm
две новости в ленте подряд :
В 2010 году в Москве не начнут строить ни одну новую дорогу
В России перестали дорожать новые машины
готовьтесь ..
|
October 21st, 2009
03:44 pm
китайцы продолжают творить чудеса:
http://auto.lenta.ru/news/2009/10/21/chinaproduction/
а здесь ещё про них и псевдо-президента:
http://ej.ru/?a=note&id=9550
коты вернулись из очередного отпуска и воюют с отоплением в норе
потом будут воевать с тырнетом
война с яблоками, похоже, уже проиграна ..
|
October 6th, 2009
12:47 pm
немного циферок .. для общего образования
http://lenta.ru/news/2009/10/05/othod/
|
October 5th, 2009
05:18 pm - оказываецца
федорино коре (тм) переименовали в просто федорино
http://ru.wikipedia.org/wiki/Fedora
|
October 2nd, 2009
03:16 pm
"Глубокоуважаемые Дмитрий Анатольевич и Владимир Владимирович!
Мы считаем своим долгом обратить ваше внимание на катастрофическое состояние фундаментальной науки в стране. Регресс продолжается, масштабы и острота опасности этого процесса недооцениваются. Уровень финансирования российской науки резко контрастирует с соответствующими показателями развитых стран. Громадной проблемой для России был и остается массовый отток ученых за рубеж"
http://www.hep.phys.soton.ac.uk/~belyaev/open_letter/
|
September 23rd, 2009
05:52 pm
хорошо в деревне летом :о))
было :о((
кончилось лето .. и деревня тоже потихоньку того-с
есть, конечно, специальные дачные деревни - на берегу крупных водоёмов недалеко от райцентра или вблизи объектов массового паломничества, но в общем и целом - постепенно растворяются в окрестных лесах
|
August 5th, 2009
04:38 pm
Программер на боевом посту
Подходы, методики, языки
Для каждого кусочка кода надо найти отображение между проблемной областью и системной семантикой, которая может решить проблему. Очевидно, чем меньше вариантов отображения, тем легче найти подходящий, особенно если он существует. Как каждая проблемная область, так и каждая проблема в ней характеризуется некоторым уровнем сложности. Редко можно изменить определение проблемы так, чтобы управлять уровнем сложности, хотя это и желательно. Обычно, чтобы найти наиболее эффективный путь сделать работу, можно лишь поиграть с системной семантикой.
На одном конце спектра возможностей готовая система, которую можно просто запустить и получить результат. На другом - набор инструкций процессора, с помощью которых можно осуществить любое физически возможное действие. Между этими крайностями есть несколько уровней, которые облегчают отображение путём ограничения семантики.
В этой терминологии язык является некоторым мешком с семантикой. Например, С или Excel являются такими мешками, которые не содержат однако рецепта для решения проблемы. Специализированные для определённых предметных областей языки позволяют проще найти отображение для проблемы из этой области. Критерием выбора языка может служить простота отображения (наиболее простая программа) для данной проблемы. За исключением тривиальных случаев, выбор требует хорошего знания особенностей всех имеющихся мешков.
Несколько сложнее представить в этих терминах методику. Обычно методика подразумевает некоторый процедурный подход к решению проблем, но мы уже выяснили, что процедуры решения проблем не существует. Однако можно определить что-то немного другое - сам подход.
Подход можно представить как совет одного опытного картографа другому как наилучшим образом браться за решение данного вида проблем. Это лишь приглашение взглянуть на проблему под определённым углом, даже если оно оформлено как перечень процедур. Директива "нарисуйте диаграмму потоков данных для поступлений за неделю" из книги "как построить платёжную систему" означает "ограничьте мир системой ввода пакетных данных и рассмотрите движение всех пакетов данных в мире".
Как и язык, подход становится тем проще, чем больше он привязан к предметной области, и так же сложно его выбрать без понимания особенностей всех доступных подходов и самой проблемы. Возможный путь развития для хороших программистов - изучение сильных, глубоких подходов и создание новых подходов для новых проблем. Всегда будут толпы людей, использующих один и тот же подход как ритуал для написания такой же платёжной системы для очередного клиента. Они даже могут обучаться "самым новейшим методикам", но всегда останутся служителями культа, и разрыв между ними и программистами будет увеличиваться.
Есть языки, привязанные к определённым подходам. Smalltalk требует видения мира как набора объектов, Lisp тесно связан с лямбда-исчислением, что приводит к предложению еды из собаки вместо предложения накормить собаку.
Ещё раз подчеркнём, что языки реальны, подходы реальны, а методики есть вымысел, часть коллективного воображаемого. Непонимание этого и неудачный выбор подхода могут привести к ситуации, когда важные части задачи не рассматриваются, поскольку лежат вне выбранного подхода, а те, кто пытается всё-таки в них разобраться, встречают сопротивление коллег, поскольку действуют не по методике и, значит, непрофессионально. Это ещё один пример барьера между картографами и заготовителями.
Интересные методики состоят сразу из подхода и языка. Структурный дизайн Джексона (JSD) рассматривает задачи с чётко определяемыми свойствами и содержит детальные указания, как с ними обращаться. Если смотреть в оба глаза, JSD может хорошо послужить в своей области. За её пределами он не работает и не является средством решения любых задач.
В JSD есть артефакт того времени - алгоритм преобразования полученных диаграмм в код вручную. Сегодня он написал бы генератор кода, но на самом деле его диаграммы можно рассматривать как язык программирования, то есть он создал язык программирования для специализированного отображения области задач.
То же самое относится и к Бучу с его UML, и к каждой интересной методике. В ранних работах он и Румбаух тоже не использовали кодогенераторы, а показывали, что трансляция диаграмм является рутинной ручной работой, значит, несложной.
Создание языка и подхода, специализированного для области, само по себе большое достижение. Для этого авторы долго изучают задачи под разными углами, создают подход и язык исходя из этого опыта. Однако многие не выделяют то креативное мышление, которое потребовалось для поиска отображения между задачей и языком. Вместо структурированного представления их подхода и предложения эвристик для видения задач в его терминах, они используют процедурный язык и дают указания что и как надо делать.
Если слепо следовать указаниям вместо осознанного создания карты, то результаты зависят от попадания в проблемную область, то есть от везения. Джексон специально объясняет, как определить, попадает ли в его область задача. Буч включил главу о том, как правильно определять объекты, что непосредственно касается вопросов картостроения. Наконец, книга Страуструпа написана картографом, у которого нет внутренних противоречий.
|
12:12 am
Четверо блоггеров были задержаны сегодня в Уфе. Их обвиняют в экстремизме и разжигании ненависти и вражды.
Четырёх жителей Уфы задержали за то, что они публиковали в интернете на сайте «Уфа губернская» запрещённые материалы. Как сообщает радио «Свобода», трое из задержанных сегодня Сергей Орлов, Константин Нестеров и Игорь Кучумов являются журналистами, выступавшими с резкой критикой правительства республики. Их обвиняют в призывах к экстремистской деятельности и возбуждение ненависти либо вражды. Четвертый задержанный Николай Швецов является общественным деятелем и одним из спонсоров сайта «Уфа губернская», где публиковались противозаконные материалы. Ему уже помимо озвученных правонарушений вменяется призыв к массовым беспорядкам. Добавим, что все четверо как сообщает сайт следственного комитета по Башкирии, были задержаны в рамках уголовного дела 2008 года. Оно было возбуждено по факту публикации на сайте «Уфа губернская» выдержки из книги Айрата Дильмухаметова «Воины против ублюдков», содержащей высказывания, призывающие к противоправным и экстремистским действиям.
В ближайшее время суд должен избрать для четырёх задержанных блоггеров меру пресечения. В следственном Комитете настаивают на том, чтобы они были арестованы.
(с) эхо
не забывайте вешать замочег, когда пишете как оно есть на самом деле ..
|
July 31st, 2009
04:31 pm
Хорошая композиция и бенефиты
Определение хорошей композиции из курса изобразительных искусств "если убрать или изменить один из элементов, то целое изменится". Возможно, это морской пейзаж с маяком, который образует вертикаль с одной стороны, направляя взгляд и противопоставляя себя волнам. Если заменить благородный маяк на урну для мусора, картина будет означать что-то другое. Если волны заменить на пятно нефти или пляжную толпу, это также изменит впечатление от картины.
Общий смысл в том, что не должно быть чего-то, что не несёт точно определённой цели по отношению к другим элементам композиции. Художник должен сохранять контроль над смыслом картины, а если она содержит случайные кусочки, то они вызывают непредсказуемые ассоциации у зрителей и ухудшают восприятие отношений между главными элементами.
Логики, изучающие систему аксиом, сталкиваются с тем же самым. Они говорят, что система должна быть "необходимой и достаточной". Необходимость и достаточность позволяют ясно видеть природу рассматриваемого явления и гарантируют, что следствия действительно относятся к рассматриваемой области, а не являются произвольными.
К сожалению, при разработке софта часто требуется функциональность, которую создают настолько быстро, насколько это возможно. Созданная функциональность становится частью пейзажа, и все участники проекта попадают в эту ловушку. Хотя это явление и выглядит неизбежным злом, есть люди, вырвавшиеся из заколодованного круга, и с точки зрения программирования как искусства, можно показать, как они это сделали.
Основная сложность в сохранении контроля над унаследованными структурами, являются ли они особенностями процесса заказчика или древней системой индексирования, это время. Иногда это называют ценой, но редко это на самом деле цена. Это дедлайны, та суровая реальность, над которой разработчики не властны. Это нормально - надо лишь относиться к ним реалистично и решать их проблемы вместо того, чтобы использовать их как оправдания в плохом качестве продукта.
Первая линия обороны против дедлайнов заключается в прозрачной среде, без странных флагов или функций, несовместимых соглашений о вызовах, разных соглашений об именах и подобного мусора. День после чистки стоит больше дня до чистки, поэтому сначала надо провести чистку в самом начале, когда весь проект впереди. Чистку придётся делать почти в любом случае - большинство организаций помещают в репозиторий первый же код, который прошёл всё тестирование. Это неважно - сделайте очистку на этом этапе, протестируйте код и приведите его в тот вид, который позволяет всё ясно видеть.
Основная сложность на этом этапе - реалистичная оценка продолжительности очистки. Чем больше мусора, тем больший эффект от очистки, но тем больше риск, что не хватит времени. В таких случаях может помочь вопрос "насколько сложна внешняя функциональность?" - если она небольшая, то можно рассчитывать на постепенное улучшение методом последовательных упрощений, даже если не видно всего пути.
Вторая линия обороны использует экспоненциальное уменьшение сложности программ. Если упростить алгоритм, его реализация будет проще и занимать меньше кода. Чем меньше кода, тем проще видеть его структуру и уменьшить количество багов. В то же время, меньше кода означает меньше синтаксических ошибок, меньше изменений, меньше тестов. Команда разработчиков числом больше пяти через некоторое время вязнет в процессе взаимных патчей, доступ к репозиторию становится самым узким местом. Откладывать решение проблем на более поздние стадии означает заложить бомбу с часовым механизмом, которая взорвётся тогда, когда поздно будет пить боржоми. В то же время, несколько напряжённых дней, потраченных на разрешение ситуации сразу же, могут надолго восстановить процесс.
Третья линия обороны - "комната скунсов", маленький, часто изолированный исследовательский отдел, функционирующий самостоятельно, практически без контроля начальства. Это страшное оружие может использоваться опытными командами или просвещённым начальством, его работу мы рассмотрим дальше.
В эпоху индустриального строительства мы имеем дело со многими физическими объектами (например, кирпичами), которыми неудобно управлять. Вместо того, чтобы сравнивать кучи кирпича с эталонными, чтобы определить необходимое количество, мы их считаем. Этот переход от физического уровня к информационному даёт нам огромное преимущество в управлении. Когда у нас есть множество чисел о поставках, транспорте и потребностях, их надо организовать в шаблоны. Мы составляем таблицы, и переход от информационной к концептуальной абстракции опять даёт преимущество.
В такой области информационных технологий, как программирование, мы не начинаем с физического уровня и не получаем преимуществ с переходом на информационный. Мы начинаем с информационных требований и должны управлять ими при помощи информационных инструментов, в силу как хороших причин, например, для взаимодействия с заказчиками и коллегами, так и плохих, как слишком буквальное применение технологии разработки для управления информационными "кирпичами" вроде измерения производительности количеством строк кода.
Проблема в том, что мы не получаем преимуществ. Результаты обсуждения могут быть больше, чем предмет обсуждения, то есть обсуждение принесло отрицательное усиление. Мы можем получить выигрыш, только применяя новый кусок информации много раз или получая многократную выгоду от его использования вместе с другими частями.
Остаётся только одна возможность - использовать понимание, чтобы достичь преимуществ в области информации. "Комната скунсов" иногда воспринимается как отход от процесса в интересах креативности, но это совсем не так. Для такой работы нужна высокая концентрация опытных профессионалов, которые могут заменять понимание, заключённое в процессе, пониманием, заключённым в личном опыте. Это необходимое условие для "комнаты скунсов". Отход от детального процесса с его персональной защитой в виде простых определённых задач несёт неизбежный риск. Все должны понимать, что возможны ошибки, и результаты могут не соответствовать ожиданиям или противоречить существующим методам управления. Но когда это работает, это работает превосходно.
Все успешные стартапы являются "комнатой скунсов". Так же, как и провалившиеся. Скунсы могут превратить большой риск потери поддерживаемости проекта в меньший риск увеличения времени разработки, то есть в определённых ситуациях это эффективный инструмент управления рисками.
|
July 29th, 2009
06:56 pm
Знание, а не кликанье
Программеры дороги, не так, как раньше, но всё-таки. Результаты их работы должны приносить прибыль компании. Проблема в том, что заготовители считают результатом только то, что можно пощупать и сосчитать. Результаты процесса разработки программ состоят в первую очередь в понимании проблемы, тестировании этого понимания в суровом виде собраных бинарников и вовсе не в кликанье при набивании кода в процессе изучения. Конечный результат - это то понимание, к которому они пришли по завершении процесса.
Иногда понимание проблемы показывает значительно более лёгкий путь, чем тот, с которого начинали. Обычный камень преткновения картографов и заготовителей состоит в том, что картографы увидели новый способ всё переделать как следует за короткое время и избавиться от недостатков существующего кода. Заготовители думают, что эти гады пытаются уничтожить всю их работу (как будто нет бэкапов) и повторить несколько ужасно тяжёлых первых месяцев разработки. Они совершают крестовый поход, чтобы остановить картографов, и в результате организация лишается лучшего понимания проблемы, поскольку его нельзя использовать в контексте существующего кода.
Умные организации больше хотят понимания, чем кода, который можно получить из понимания. Организации, погрязшие в моделях массового производства, не учитывают понимание как таковое, а признают только ценность кода, сложенного высокими штабелями.
|
04:16 pm
Уровень качества
Когда картёжник создаёт карту проблемной области и улучшает её, он должен понять, когда остановиться. Это относится ко всем уровням разработки. Обычно существует решение, которое существенно проще других и очевидно минимально. Может быть несколько способов его выражения, но они обозначают по сути одно и то же. Хотя высказывания типа "вы это узнаете, когда увидите" несомненно правильны, они не говорят, куда смотреть.
В качестве примера можно привести функцию для Win32 из книги Рихтера, которая, несмотря на попытку достичь максимальной ясности, не была упрощена в силу принятых соглашений:
DWORD WINAPI SecondThread (LPVOID lpwThreadParm) {
BOOL fDone = FALSE;
DWORD dw;
while (!fDone) {
// Wait forever for the mutex to become signaled.
dw = WaitForSingleObject(g_hMutex, INFINITE);
if (dw == WAIT_OBJECT_0) {
// Mutex became signalled.
if (g_nIndex >= MAX_TIMES) {
fDone = TRUE;
} else {
g_nIndex++;
g_dwTimes[g_nIndex - 1] = GetTickCount():
}
// Release the mutex.
ReleaseMutex(g_hMutex);
} else {
// The mutex was abandoned.
break;// Exit the while loop.
}
}
return(0);
}
Однако мы можем сделать это и достичь максимального уровня качества
DWORD TheThread(void *ThreadParm)
{
while(Index < MAX_TIMES &&
WaitForSingleObject(Mutex, INFINITE) == WAIT_OBJECT_0)
{
if (Index < MAX_TIMES)
Times[Index++] = GetTickCount():
ReleaseMutex(Mutex);
}
return(0);
}
Причём вместо
hThreads[0] = CreateThread(..., FirstThread, ...);
hThreads[1] = CreateThread(..., SecondThread, ...);
можно писать
hThreads[0] = CreateThread(..., TheThread, ...);
hThreads[1] = CreateThread(..., TheThread, ...);
и тем самым избежать поддержки нескольких версий одного и того же кода.
|
|
|