Форум о банкротстве и продуктах «РИТ»

[vva]

был вопрос о том, где брать материал на тему "Оптимизация работы с базами данных"

большую часть доклада можно делать по материалам (по крайней мере я на это ориентировался)
http://dev.mysql.com/doc/refman/4.1/en/ ... ation.html

только найти это место в русской документации здесь (нужно выкачивать zip файл):
http://dev.mysql.com/doc/index.html

там почти про всё есть

можно использовать и другие СУБД и материалы, принципы на самом деле везде одинаковые

[vva]

к вопросу о маркетинговых позиционирующих слоганах:
:D
http://katy-m.livejournal.com/53920.html
------------------
Русская грамматика как средство борьбы с российским законодательством

Как известно, действующий Закон о рекламе запрещает некорректное сравнение рекламируемого товара с конкурирующими образчиками продукции. Причем некорректность сравнения, как правило, трактуется максимально расширительно, - буквально настолько, что любое сопоставление с конкурентами может рекламистам выйти боком. То есть, нельзя вот так прямо сказать: "Презервативы "Пятиминутка" в пять раз лучше презервативов "Минутка" - удовольствие длится дольше!" Потому что мужчины разные бывают, и если у одного из них удовольствие вдруг не дотянет до нужного предела, он с легкостью может у производителя гондонов отсудить миллиона два за порушенную интимную жизнь. Но еще скорее до оного производителя доберутся контролирующие органы, грудью встав на защиту гипотетических страдальцев полового фронта, у которых вдруг в пять раз дольше не получится. В итоге дорогостоящий ролик придется переделывать - и хорошо еще, если обойдется без штрафных санкций. Чтобы обойти эти законодательные рифы, умные люди в свое время изобрели "обычный порошок", "обычный отбеливатель" и прочих неназываемых монстров.
Еще хуже, с точки зрения действующего Закона о рекламе,обстоят дела с использованием превосходных степеней. Их, по закону, нельзя использовать вообще. То есть, заявить в рекламном ролике - "Наш гаш - лучший гаш, покупай гаш только наш!" нельзя даже ради хорошей рифмы и размерности строки. Потому что научно обоснованного сравнения образца продукции со всеми буквально существующими провести невзоможно. А необоснованные сравнения некорректны и потому запретны, смотри предыдущий абзац. Чтобы все же ввести в свои ролики и принты победительные абсолютные формы, рекламистам приходится прибегать к интеллигентски-уклончивым вводным словам - типа, "... возможно - лучшее пиво в мире" и прочим "кажется" и "вероятно". Которые поселяют в части целевой аудитории тревогу и неуверенность в своем выборе, - но что поделаешь, если закон такой.

Это я к чему? К тому, что я тут вчера случайно услышала новый рекламный ролик шампуня "Супер-Пупер Уход" от известного производителя. И я утверждаю, что создатели этого ролика - абсолютные долбанные гении словоформы и вдохновенные творцы грамматической конструкции. Потому что они смогли обойти все вышеописанные запреты, использовав превосходную степень в ее абсолютном победительном виде, безо всяких вот этих интеллигентских оговорок. И при этом - в полном соответствии с Законом о рекламе. Правда, получившийся слоган умеющую слушать часть населения может не просто фрустрировать, а прямо-таки вогнать в депрессию не хуже таблички "Выхода нет" на дверях метро. Но это уже мелочи. К тому же, истинный смысл гениального слогана прозреваешь не сразу - подавляющее большинство целевой аудитории еще до того, как прозреть, успеет смести шампунь "Супер-Пупер Уход" с полок окрестных магазинов. А слоган, собственно, следующий:

ШАМПУНЬ "СУПЕР-ПУПЕР УХОД".
НИЧТО НЕ СДЕЛАЕТ ВАШИ ВОЛОСЫ СИЛЬНЕЕ.
------------------

[vva]

докладывала Ившина на Тему 3. "Общие знания, которые должны быть одинаковыми у дизайнеров и программистов"
доклад мне понравился (оценка 5), почти всё именно так как я и хотел за исключением некоторых маленьких замечаний и немножко во времени не уложились.

по замечаниям:

1. модальная сетка - конечно же модульная.. моя опечатка-ошибка, материал можно посмотреть тут:
http://www.htmlbook.ru/content/?id=79
http://www.nundesign.com/st/35.html
http://www.compuart.ru/Archive/CA/2003/4/19/
http://drawyourdesign.blogspot.com/2007 ... _2378.html
http://studiomaximum.net/doc/index-23.php
http://www.hardline.ru/8/68/4190/

2. по цветовым моделям (HLS которая - так и не раскрыли толком), посмореть тут:
http://ru.wikipedia.org/wiki/HSV
http://ru.wikipedia.org/wiki/HLS

3. по тому чего точно следует избегать в дизайне, я ориентировался на старую книжку Кирсанова:
http://alsut2007.narod.ru/object/Progra ... design.pdf

искать слова "избег"..

на паре отсутствовали
Серебрянников, Белякова, Пишков, Пушин

соотвенно их оценка на в среднюю оценку на "автомат" пойдёт как 0

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

[vva]

Прошу на будущее всех докладчикав расчитывать время доклада..

пара - 90 минут
10 минут - вопросы и прочая ерунда
итого 80 минут на 10 тезисов - по 8 минут в среднем на тезис или если считать среднюю скорость чтения лекции 125 слов (читаем здесь: http://www.mentalitet-edu.ru/learn_to_learn.php ) в минуту - в среднем по 1000 слов на тезис или по 10000 слов в докладе.

Посмотреть сколько слов в вашем докладе можно воспользовавшись функцией word а (Сервис/Статистика). В моей лекции по маркетингу например 9463 слова, и то я еле уложился.

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

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

[vva]

на лекциях задавались вопросы:

1. по растеризации отрезка (молодой человек открыл какой то свой алгоритм)

на самом деле тема старая и давно отработанная
искать по словам "алгоритм брезенхема" (брезенхейма) - растеризация без антиалиасинга
"алгоритм Ву" - растеризация с антиалиасингом
или если угодно
"Алгоритм DDA-линии" - растеризация на точках с вещественными координатами


всё это старые, быстрые и надёжные алгоритмы

изобретать велосипеды конечно полезно, чтобы мозги не загнили (сам открывал кучу), но всё таки эффективнее бывает искать готовые решения

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

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

[vva]

взяли темы и задачи следующие студенты:

14. Вахрушев: тема 7, задание 26
16. Шадрина: тема 4, задание 30 (решила делать доклад вместе с Ведерниковой)
21. Щелчков: тема 7, задание 34
22. Пушин: тема ?, задание 25

осталась только задача
задание 35 "система расчёта участка теплоснабжения"
которая видимо уходит на так и непоявившегося на занятиях Пишкова

так, если кто ещё не понял, пора начинать показывать результат практической работы!
я обычно заставляю переделывать работу 5-10 раз, не меньше
так что те кто надеется сдавать всё в самый последний момент перед экзаменом рискуют просто неуспеть (такое было в прошлом году, человек получил двойку на экзамене по этой причине)

[Marysenka]

Виктор Александрович, вы кое-что перепутали. Я действительно делаю доклад по теме 4 вместе с Лизой Ведерниковой, но практическую задачу я не меняла. Я выполняю задание 30, а не 36.

С уважением, Мария Шадрина

[vva]

да, ошибся, копи-паст не потёр

[Marysenka]

*help* Виктор Александрович, поясните пожалуйста, 10ый тезис в теме 4 ("задача управления проектом как поиск оптимальной траектории роя разработчиков") или хотя бы намекните, что называется "роем разработчиков"...

[vva]

ага, тут и в прошлом году вопросы возникали

вообще я может недостаточно точно выражаюсь, просто хотел провести аналогию с "теорией оптимального управления в динамических системах", например постановку задачи можно помотреть тут:
http://vvo.psati.ru/files/RPU/page2.fil ... MinE_6.htm
http://www.webknow.ru/ostalnie_00126.html
http://www.bestreferat.ru/referat-52337.html

для образования которое получал я (+01.02 - в частности дифф уры нам читали как приматам), эта аналогия вполне ИМХО должна находить отклик в понятийной базе. У вас же я чувствую совсем другая ситуация (не уверен что вам вообще читали дифф уры), поэтому переложу свою мысль на футбольные термины.

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

В начале проекта "со своего поля" руководство даёт начальное "управляющее воздействие" всем членам, назначает им намеченную цель и посылает их туда пинком.

Идеальный мячик-разработчик внутри которого присутствует какая то интеллектуальная начинка конечно сам неплохо понимает и быстро "захватывает" конечную цель и катится в ворота по кратчайшей траектории.

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

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

В качестве параметров траектории ракет и мячиков выступают текущие координаты (x,y,z) и их производные (вектор скорости).

Для разраюботчика в качестве координат выступает то на какой стадии выполнения своего задания он находится, в качестве производной слева - то что он сделал за отчётный период, в качестве производной справа - то чего он планирует достичь за следующий отчётный период (куда он движется). А в качестве "управляющего пинка" корректируется задача "чего он должен достичь", возможно с соответствующими орг выводами и мотивировкой.

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

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

В аналогичной ситуации находится и руководитель проекта, который тоже должен регулярно корректировать свои планы (см. например http://www.ashmanov.com/pap/ashrul2/#11 ).

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

В общем и целом такая система управления на базе целей-отчётов-пересмотре целей наиболее полно разработано в методологии Scrum ( http://en.wikipedia.org/wiki/Scrum_%28development%29 или по русски: http://www.osp.ru/os/2007/04/4220063/), более того, Scrum при правильном применении должен разгружать руководителя, так что нормально сработанная команда сама летит к правильной цели при минимальном воздействии извне и по ходу дела компенсируя косяки отдельных членов команды.