Artazor’s Minds

Ещё один блог обо всём

Советы экзаменатору

leave a comment »

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

  1. Прежде всего разъясните экзаменуемому, что вся его профессиональная карьера может рухнуть из-за его неудачного ответа. Подчеркните ему важность ситуации. Поставьте его на место с самого начала.
  2. Сразу задайте самые трудные вопросы. Если первый вопрос достаточно труден или запутан, экзаменуемый слишком разнервничается, чтобы отвечать на следующие вопросы, как бы просты они ни были.
  3. Обращайтесь к экзаменуемому, сохраняйте сдержанность и сухость, с экзаменаторами же будьте весьма веселы. Эффектно обращаться время от времени к другим экзаменаторам с насмешливыми замечаниями по поводу ответов экзаменуемого, игнорируя его самого, как будто его нет в помещении.
  4. Заставляйте экзаменуемого решать задачи вашим методом, особенно если этот метод необычен. Ограничивайте экзаменуемого, вставляя в каждый вопрос множество указаний и оговорок. Идея состоит здесь в усложнении задачи, которая без этого была бы весьма проста.
  5. Вынудите экзаменуемого сделать тривиальную ошибку, и пусть он ломает голову над ней как можно дольше. Сразу же после того, как он заметит ошибку, но как раз перед тем, как он поймет, как ее исправить, презрительно поправьте его сами. Это требует высокой проницательности и точности выбора момента, что достигается только большой практикой.
  6. Когда экзаменуемый начнет тонуть, никогда не помогайте ему выкарабкиваться. Зевните… и перейдите к новому вопросу.
  7. Задавайте экзаменуемому вопросы типа: «Разве вы не проходили этого в начальной школе?»
  8. Не позволяйте задавать экзаменуемому выясняющие вопросы и никогда не повторяйте собственные разъяснения и утверждения.
  9. Каждые несколько минут спрашивайте не волнуется ли он.
  10. Наденьте темные очки. Непроницаемость нервирует.
  11. Заканчивая экзамен, скажите экзаменуемому: «Ждите за дверью. Мы вас вызовем».

Взято с Золотого Гиперкуба

Written by artazor

Январь 4, 2011 at 6:36 дп

Опубликовано в Преподавариум

Объективное интернет-голосование: Возможно ли это?

leave a comment »

Результаты интернет-голосования, зачастую показывают показывают только одно – количество друзей у кандидата в призёры (и друзей их друзей). А вовсе не объективные характеристики кандидата: будь то красота девушки на оцениваемой фотографии, душевность рассказа на литературном конкурсе и т.д.
Здесь я расскажу как силу интернет-сообществ обратить во благо и сделать голосование более объективным

Схема, которую я предлагаю может быть и не нова (тогда предлагаю поделиться опытом — умудрённым). Если же нет — то возможно кому-то она пригодится, тогда назовем её Vote-Boost!

Синергетика  Web 2.0

Современная интернет-аудитория, почувствовавшая вкус Web 2.0, способна практически мгновенно образовывать сплочённые сообщества и оказывать значительные влияния на любые параметры, которые выставлены для оценки или голосования на открытом интернет-конкурсе.

В случаях, где от результата голосования зависит моральное или материальное благо для некоторого конкретного человека, а от отдающего голос требуется совершить элементарное действие, в Web 2.0 образуется (зачастую по пирамидальному принципу) «группа поддержки», члены которой могут даже лично не быть знакомыми с исходным человеком-кандидатом (тем, кому достанется приз в случае успеха — такого человка мы называем «номинальной целью» группы поддержки). При этом, каждый член группы ЗАИНТЕРЕСОВАН в победе этого человека, поскольку, отдавая свой голос за предложенного кандидата, он, практически ничего не затрачивая, делает психологическое одолжение (или возвращает долг) человеку, который попросил поддержки этого кандидата.

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

Сюр-Конкуренция

Иногда от групп поддержки отпочковываются другие, конкурирующие, группы поддержки (которые обычно быстро начинают догонять по численности исходную группу). Это происходит, когда «просьба проголосовать» доходит до социально-активного участника, который в силу своих привязанностей (или других соображений) избирает себе новую «номинальную цель». Причём он осведомлён о размерах уже существующей группы, поэтому начинает прилагать удвоенные усилия по организации «конкурирующей группы поддержки».

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

Во зло или во благо?

Что делать с «группами поддержки» организаторам конкурса? Нужно ли с ними бороться? Можно, конечно, пытаться сбрасывать накрученные таким образом оценки. Но при этом есть риск войти в конфликт с сообществом и потерять авторитет. Можно подстраховываться – разделяя интернет-голосование с оценками независимой оффлайновой судейской коллегии. Но при количестве заявок превышающих 20-30 штук никакая судейская коллегия не сможт обеспечить истинно объективную оценку. Ведь для такой оценки каждый судья должен независимо ознакомиться с каждой заявкой. Что негуманно по отношению к судьям. Поэтому, это – не тот подход, который надо использовать. Оказывается МОЖНО ЭФФЕКТИВНО ИСПОЛЬЗОВАТЬ эти группы поддержки, при этом подняв на новую высоту РЕАЛЬНЫЕ качества оцениваемых объектов. При этом с большой вероятностью победит САМАЯ КРАСИВАЯ девушка, САМЫЙ ИНТЕРЕСНЫЙ рассказ и т.д. Каким образом этого достичь?

Обращение силы нападающего

Первое, что нужно сделать — это смириться с существованием групп поддержки и признать, что большинство из пришедших на сайт – пришли проголосовать за «своего». При этом, нужно заставить голосующего кроме своего кандидата, обязательно проголосовать за ещё одного из [как минимум двух] случайных (на самом деле не совсем случайных – см. ниже) кандидатов, которых мы назовём «сателлитами».

При показе интернет-страницы голосования, всех трёх кандидатов, подлежащих оцениванию, обязательно следует расположить НА ОДНОЙ так, чтобы принимать результат голосования по ним всем единой формой (за одну отсылку). Но, при этом, страница должна быть посвящена именно одному – целевому кандидату и это должно быть ясно посетителю (подчёркнуто дизайном, логикиой и т.п.) – мол основной – вот он кто, и для того, чтобы отдать ему свой голос – поддержите одного из вот этих сателлитов (рассказов [фотографий красивых девушек и т.п.])

Голос за целевого кандидата считается принятым, только если также отмечен один из кандидатов-сателлитов.

При отображении страницы целевого кандидата с сателлитами – набранные очки разрешается показыать только для целевого кандидата. Очки, набранные сателлитами должны быть скрыты. Их [очки] посетитель может отыскать только на целевых страницах, посвящённых специально тем кандидатам как основным (но отыскать их можно лишь специально разыскивая – никаких ссылок на эти страницы со страницы оцениваемого кандидата быть не должно: прямые ссылки на страницы голосования должны быть только в общих каталогах и/или на вертушке главной страницы проекта).

Таким образом, очки кандидату будут поступают из двух источников:

  • необъективного – от группы поддержки, тех, кто пришёл на страницу специально (по ссылке, полученной от друга) – очки X;
  • объективного – от стронних голосующих, тех, кто проголосовал за кандитата, увидев его в качестве сателлита – очки Y.

Эти очки необходимо подсчитывать и хранить раздельно. Но при отображении суммировать с определёнными коэффициентами A*X + B*Y .

Коэфициент для очков от группы поддержки всегда должен быть равен единице A = 1

А очки от сторонних групп должны быть более ценными (Коэффициент B > 1).

Если проект планируется на 1000 соревнующихся – этот коэффициент может достигать 10. Вообще, его можно увеличивать динамически – как кубический корень из количества заявок N. Причём и количество очков, отдаваемых сателиту при голосовании за целевого кандидата, должно зависеть от количества текущих собственных [не от чужих групп] очков X, набранных целевым кандидатом (Например 1/10 от их количества – точнее коэффициент 1/B, обратный B). Это позволяет простым смертным выигрывать от соперничества конкурирующих групп поддержки. Но это всего лишь общие предложения – в зависимости от специфики голосования коэффициенты могут быть другими. В самом простом случе их просто можно суммировать (только при подсчёте, при одинаковом количестве очков, нужно будет отдавать предпочтение тому у кого сторонних очков больше).

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

Принцип показа сателитов – случайный, но не совсем – для каждого кандидата хранится число Z – сколько раз этот кандидат был показан на страницах голосования в качестве сателита (учитываются только те показы, которые закончились голосованием но НЕ ВАЖНО в чью пользу). Для показа в качестве сателлита выбирается кандидат с минимальным Z. Это обеспечивает честную ротацию показов при голосованиях.

Побочный эффект

При этом отпадает необходимость ограничения на количество голосований с одного IP адреса в день. Пусть хоть весь день голосуют.

Written by artazor

Декабрь 30, 2008 at 9:32 дп

SCSF April 2008 Fix for Visual Studio 2008 SP1

with 12 comments

Smart Client Software Factory April 2008
Fixed for VS 2008 SP1 (MSI-Package)
DOWNLOAD
WARNING:
This is not an official release of SCSF Guidance Package.

Please read NEXT FEW lines carefully to understand if it suits for you.


April’s 2008 official release unfortunately has several known issues on VisualStudio 2008 SP1

This package is provided for you by AAR only as a result of careful applying patches described at the CodePlex SCSF knowledge base website to the Aplil’s source code and a minor repackaging all the result as MSI.

Use it only on your own risk.

Also this prepackaged version contains some popular binary libraries of two additional products:

These files can be found at «Lib» subdirectory under your installation path. These files are passive i.e. do not affect any exisiting installations of corresponding products.

As well this installation contains HxS Help files from the original Smart Client Software Factory, that will be integrated into VS2008 Help system during installation (the last percent of the installation progress indicator is Help merging, and it takes the most time of the overall process).

So, theoretically, this package can be used as the sufficient standalone replacement of scsf.2008.april.

Samples and Reference implementation of SCSF are not included yet, but can be included later if an appropriate feedback will be received.

Written by artazor

Декабрь 7, 2008 at 7:18 дп

Опубликовано в Девелопмент

Tagged with , , , ,

Реквием по Акрополису, Фанфары Кабу

leave a comment »

Об авторе: Уард Белл, продукт-менеджер компании DevForce .NET enterprise application development product from IdeaBlade (www.ideablade.com).

Отрывок из статьи «Реквием по Акрополису, Фанфары Кабу»

[Вольный перевод by Artazor]

… И всё же не смотря на преимущества WPF, я продолжаю рекомендовать использовать CAB/SCSF WinForms технологии для LOB (line-of-business) приложений . Даже для новых разработок.

Да-да, конечно, в моей компании мы делаем значительные успехи в WPF-овских инициативах, и я вполне оптимистичен по поводу нового поколения WPF приложений, которое появится к концу 2008-го года. Потрясающая WPF-овская архитектура связывания данных (WPF data binding) *сама по себе* изменит не только способ создания пользовательских интерфейсов, но и наши инструменты мышления о них.

Но давайте оставаться реалистами. WPF-разработка сегодня — намного сложнее аналогичной WinForms разработки.  Бедность инструментов создания WPF приложений и крутая кривая обучения как минимум на год убьют производительность разработчиков . Если вам необходимо сдать большое приложение в разумные сроки, вы должны подумать дважы перед тем, как покинуть остров WinForms: до материка вы можете и не доплыть даже зная, что он есть.

Очевидная опасность — то, что вы останетесь позади. Некоторые шутники будут острить, что ваше приложени стало «Наследством» («Legacy») еще до того как было выпущено. Хорошо если вы им скажете «у меня хотя бы ЕСТЬ релиз».

Ведь вы же можете делать классные, современно выглядящие WinForms приложения, которые прекрасно справляются со своей работой.

Когда вы будете сдавать свой продукт, другие парни будут париться над глючащими, падающими но при этом гламурно-глянцевыми WPF-фронтэндами.

Ходит множество разговоров, как WPF позволяет качественно поднять («прокачать») пользовательский интерфейс (Differenting the UI)

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

Не поймите меня неправильно. Я крайне убеждён что серьёзный, красивый и удобный пользователский интерфейс — обязателен. И вопрос не ставится в форме «Должны ли мы инвестировать ресурсы в пользовательский интерфейс?». Вопрос — другой — «Является ли WPF UI лучшей альтернативой WinForms для LOB приложений?». Ответ будет «Да». Когда-нибудь. Но не сегодня и не на следующие год, или два.

Мне ещё предстоит встретить управляемое данными LOB-приложение, которое бы использовало WPF действительно с толком. Тут я не имею в виду интерфейс с белыми фонтами на сияюще чёрном фоне, отражения картинок [типа "мокрый пол"], скруглённых краев и больших анимированных кнопок (всей той попсы, которая до одного места дядям, делающим реальный бизнес). Да, я таращился, как  тот парень, первый раз смотря как моя форма крутится на «карусели» (WPF-визуализация старого понятия переключения табов или кручения элементов в листбоксе). Это приелось на десятый раз. А в сотый раз я уже был рассержен и ждал, когда интерфейс кончит вращаться и отдаст, наконец, мне мою чёртову форму.

Я начал искать простые WPF эффекты, которые имеют смысл и право быть. Эффект имеет право быть, если от увеличивает продуктивность пользователя. Он должен помочь пользователю увиедть важное событие или важную связь более быстро и более ясно. Он должен

помочь совершать правильный выбор быстрее.

Такие эффекты обычно очень тонкие. Например однажды я увидел картинку,  увеличенную всего на 5% от её обычного размера для того, чтобы привлечь внимание к произошедшему событию. За этот эффект цепляется глаз, но при этом эффект не раздражает. Великолепно.

Я могу использовать какой-нибудь неброский эффект для того, чтобы пользователь знал, что операция «save» прошла успешно (иногда пользователю бывает важно знать об этом). Это можно сделать без типичного, назойливого прерывания работы диалогом «Save Completed».

Мы изобретаем многие из таких эффектов и они потом прочно входят в наш лексикон. Это — лексикон повседневных идиом, которые мы используем для построения эффективных пользовательских интерфейсов. Но, к сожалению, эти идиомы не существуют *прямо сейчас* и даже разработчики уровнем выше среднего плохо подготовлены для того, чтобы изобретать их самостоятельно.

Пока у нас не будет одного лексикона оправданных графических идиом на всех, преимущества WPF для создания LOB приложений минимальны.

[Читать полный текст на английском ]

Written by artazor

Ноябрь 4, 2008 at 10:38 дп

Опубликовано в Девелопмент

Tagged with , ,

Ссылка в прошлое

with one comment

Читая книгу «Programming Ruby» заметил, что авторы иногда прибегают к мотивации вида: «это можно сделать вот так…», и далее следует описание какой-нибудь красивой и лаконичной штуки, но потом для убедительности идет поучительная фраза: «…и не придется писать сотни сторк кода, как когда-то». И во многих книжках встречается то же самое. От описаний новомодных фреймворков до фундаментальных трудов по основам объектно-ориентированного программирования. Нет-нет да и сорвётся автор похвалить новый инструмент, продемонстрировав его преимущества над старым. Чего искать — сам грешен… рассказываю студентам, как раньше моделировали то, для чего теперь синтаксис есть :)

Но вот хитрый вопрос — кому адресованы такие замечания и нужны ли они вообще? Ведь для того, чтобы ощутить эти сотни сторк, нужно хотя бы однажды их написать. А вот на новичков в программировании такие замечания впечатления УЖЕ не производят. Не берут за душу. К сожалению. Сравнение инструментов как методический прием при обучении срабатывает только при условии, что изучающий уже имеет практический опыт работы с менее совершенным средством. А наша (ИТ) индустрия разогналась настолько, что технологии устаревают буквально за месяцы и выходящие на арену молодые и зеленые не могут (да и, похоже, не обязаны) знать о всех тупиковых ходах и велосипедах, которые были изобретены и существовали до этого. Программирование как наука — могло бы потребовать такого знания — для защиты диссертации, например. Но беда в том, что это уже не наука — а ремесло. И трата времени на изучение устаревших технологий уже не является инвестицией в себя. С появлением Web 2.0, клауд-компьютинга и прочих подобных, мы вошли в ту фазу, когда график развития технологий имеет (возможно локально) форму взлетающей экспоненты. А это значит, что даже если ты способен изучать технологии такими же темпами как они развиваются — если начать со старой технологии, то расстояние от тебя до авангарда будет также экспоненциально увеличиваться. И студенты это чувствуют. Так что возможно, что единственное оправданное применение таких отсылок в прошлое — это намеки талантливым и немного авантюрным тимлидам и менеджерам, вышедшим на свои уровни из среды профессиональных программистов.

Есть такое понятие в программировании — висячий указатель. Это когда кто-то держит у себя в кармане указатель, и не подозревает, что «указуемое» (то, на что указывали) — уже ушло в небытие. Прозрение наступает только тогда, когда по указателю пытаются обратиться. Но обычно результат плачевный. «Адрес верный, но адресат умер».

Written by artazor

Август 13, 2008 at 3:19 дп

Отслеживать

Get every new post delivered to your Inbox.