Хабрахабр: Коллективные / Блоги / Захабренные Голосов: 10 Адрес блога: http://habrahabr.ru/blog/ Добавлен: 2007-10-24 18:05:40 блограйдером Robin_Bad

Управление проектами / ScrumMaster — сильный лидер с правом на отстрел

2011-07-22 17:35:11 (читать в оригинале)

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

Для начала вспомним отличия традиционной системы управления — репрессивной, от гуманной и творческой Agile модели.

Репрессивная модель управления

В принципе в ней все вертится вокруг «дающего деньги» и получающих их, оказавшихся «как бы» менее удачливыми и напористыми, чтобы создать собственную компанию. Он платит и будет «вытворять» с сотрудниками сам или через «слуг» все, что захочет. Большинству деньги… нужны, все молчат и… борются друг с другом — сваливая ответственность на более слабых и нерасторопных и подставляя их когда это нужно.

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



Модель, разумеется, очень эффективна на коротких и средних дистанциях. Еще бы — вспомним Фашистскую Германию, ее бурный рост и развитие. Но… модель имеет косяки, т.к. «посеявший ветер, пожнёт бурю» (чем заканчивает владыка ситх и его последователи, мы знаем :-)).

---

Lisp / [Из песочницы] Установка common lisp на правах пользователя

2011-07-22 17:23:33 (читать в оригинале)


Есть проблема: На рабочих серверах (у нас используется политика тонких клиентов, толстых серверов) не установлено никакой lisp машины, и я, разумеется, не администрирую их.
На ум сразу приходят 2 решения:

• Уговорить администратора.
• Справиться самостоятельно.

Первый вариант подходит для настоящих внедренцев. Я к сожалению не владею достаточными аргументами, почему вдруг все терминальные сервера должны обзавестись ещё и лисп машиной.
Поэтому здесь пойдёт речь о втором варианте. (А именно о ECL на linux в custom каталоге).

---

JavaScript / Knockout, практический опыт использования

2011-07-22 17:12:07 (читать в оригинале)

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

---

Android / kedDroid – S04E02. Видеообзор софта для Android

2011-07-22 17:08:18 (читать в оригинале)

kedDroid набирает обороты, мы уже прошли три полных сезона и сейчас вы смотрите четвертый, это вторая серия. Сегодня мы смотрим на две игры и два приложения. Последние два пункта обзора, я чувствую, плотно осели в памяти моего Nexus S.

---

Поисковые машины и технологии / Построение индекса для поисковой машины

2011-07-22 17:07:26 (читать в оригинале)

Полное содержание и список моих статей по поисковой машине будет обновлятся вот здесь: http://habrahabr.ru/blogs/search_engines/123671/

В предыдущих статьях я рассказывал про работу поисковой машины, вот и дошел до сложного технически момента. Напомню что разделяют 2 типа индексов – прямой и обратный. Прямой – сопоставление документу списка слов в нем встреченного. Обратный – слову сопоставляется список документов, в которых оно есть. Логично, что для быстрого поиска лучше всего подходит обратный индекс. Интересный вопрос и про то, в каком порядке в списке хранить документы.

На предыдущем шаге DataFlow от модуля-индексатора мы получили кусочек данных в виде прямого индекса, ссылочной информации и информации о страницах. Обычно у меня он составляет около 200-300mb и содержит примерно 100 тысяч страниц. Со временем я отказался от стратегии хранения цельного прямого индекса, и храню только все эти кусочки + полный обратный индекс в нескольких версиях, чтобы можно было откатиться назад.

Устройство обратного индекса с виду, простое, – храним файл, в нем в начале таблица адресов начала данных по каждому слову, потом собственно данные. Это я утрировано. Так получается самый выгодный для оптимизации скорости поиска формат — не надо прыгать по страницам — как писали Брин и Пейдж, — 1 seek, 1 read. На каждой итерации перестроения, я использую 20-50 кусочков информации описанных выше, очевидно загрузить всю инфу из них в память я не могу, тем более что там полезно хранить еще кучу служебных данных об индексе.