Получение вычета по 3-НДФЛ и мошенники

Примерно неделю назад получил вычет по форме 3-НДФЛ на карту сбербанка Momentum.
В воскресенье вечером звонок на мобильный с номера 8-916-492-4455.

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

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

Вывод: кто-то из сотрудников ФНС, Сбербанка или почты России сливает информацию мошенникам о начислениях налоговых вычетов на банковский счет привязанный к пластиковой карте.

George Orwell 'Animal Farm'

Сегодня закончил читать "Скотный двор" Джорджа Оруэлла на английском.

Читал в метро со своего HTC Desire.
Импользуемое ПО:
- CoolReader / Adobe PDF Reader (читалки)
- ColorDict (бесплатный словарь)
- Documents To Go (текстовый редактор для записи слов)

Незнакомые или забытые слова записывал с помощью Documents To Go. В нем можно смотреть статистику по документу. По прочтении повести оказалось, что я не знаю (забыл) порядка 230 слов, основную массу которых составили слова относящиеся к сельскому хозяйству (что мне, разработчику, в общем-то простительно :)

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

Теперь, что касается самого произведения:

Краткое описание Animal Farm на википедии

George Orwell 'Animal Farm' (pdf)

Animal Farm мультфильм 1954 года

Скотный двор (фильм 1999 года) на rutracker.org

Особенно рекомендую посмотреть фильм.

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

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

P.S. В романе «1984» продолжены основные мотивы «Скотного двора» — преданная революция, опасность ограничения личных свобод, авторитарная бонапартистская диктатура, эксплуатирующая попранные ей же достижения революции. (с)

Короткий отзыв о посещений конференции "Форум технологий" от mail.ru Group

Вчера был на технической конференции, устроенной компанией mail.ru:
http://techforum.mail.ru

Коротко! Мне понравилось! Организация на 5+!
Было весело и интересно!
Обогащение знаниями сопровождалось поглощением разных вкусностей :)
Подарили сумку и всякой разной мелочи!

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

Понравилось, что не просто рассказывалось о том, как есть, а как было и почему стало так.
Так например, mail.ru начинал со стандартной связки Apache, Mysql, Perl.
Сейчас же связка у них примерно такая: Nginx + Apache, Tarantool + Valdemort, Mysql, Hadoop.
Языки программирования чуть ли не все мейнстримные, включая C#!

Надеюсь, что скоро появятся видео с докладами, чтобы не получилось как в анекдоте про Рабиновича и Карузо :)

Заставляем работать MS Word 2003 в ASP.NET из-под IIS7 на Windows Server 2008 x64

Если вы пытаетесь заставить работать Microsoft Word 2003 в ASP.NET из-под IIS 7 на 64-разрядной операционной системе Windows Server 2008, то  скорее всего получите следующую ошибку:

System.Runtime.InteropServices.COMException (0x800A13E9): There is insufficient memory. Save the document now.

Решение:

•   создайте отдельного пользователя, например, AppPoolUser, от которого будете запускать пул приложений IIS

•  Добавьте этого пользователя обязательно (!) в группу локальных администраторов (!) и группу IIS_IUSRS

•  В web.conig'е сделайте имперсонацию:

    <system.web>
      ...
      <identity impersonate="true" userName="AppPoolUser" password="123456" />
      ...
    </system.web>

• Создайте обязательно (!) в директории: C:\Windows\SysWOW64\config\systemprofile папку Desktop

  Ниже не делал, заработало и так:
- Open Regedit, Go to HKEY_LOCAL_MACHINE\SOFTWARE\Classes\AppId and edit the two enteries that have a Guid ending with 46. Delete every key they have and add a new key called RunAs with the value of Interactive User

Особенности работы с Xbase DBF через OleDb провайдер

Относительно недавно наткнулся на довольно интересную проблему, описанную мною на ломанном английском при работе с .dbf файлами через OleDb провайдер.
Описал ее на форуме MSDN в этом топике:

Create index command hangs up on dBase III .dbf file


В двух словах, нижеприведенный код зависал намертво при выполнении метода ExecuteNonQuery:

string createIndexCmd = "CREATE INDEX [INDNAME] ON [TBLNAME]([FIELD1], [FIELD2]);";
  using (var oledbCommand = new OleDbCommand(createIndexCmd, oleDbConnection))
   oledbCommand.ExecuteNonQuery();
 }

Там же в топике мною было описано и решение этой проблемы.

Но это так, к слову...


XBase DBF морально устарел, но еще используется в унаследованном коде.

Что можно использовать вместо него?

Все, конечно, зависит от конкретной задачи, которую вы собираетесь решать...

Советую присмотреться в первую очередь к SQLite, Firebird, SQL Server Compact.

К SQLite в первую очередь! Много положительных отзывов, поддержка для .Net, кроссплатформенность.

Сын родился!!! :))))))))

22 сентября 2011 года в 20 часов 11 минут в 15 ГКБ г. Москвы на свет появилось маленькое чудо, мой сын, Мирослав.

В животе у счастливой мамы он успел вырасти до 55 сантиметров и набрать вес 3490 грамма.

Несмотря на обвитие плода, роды прошли быстро (за 5 с половиной часов и хорошо, поставили 8/9 балла).

Выразить словами и цифрами испытываемые чувства, к сожалению, не в моих силах :))

Я просто счастлив! :) Ура!

Осталось дело за малым - вырастить его здоровым, и воспитать сына Человеком (с большой буквы) :)

Don Omar - Danza Kuduro ft. Lucenzo

Рассея, моя Россея!

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

    Хантер С. Томпсон. Страх и отвращение в Лас-Вегасе, 1971

Чтобы такого почитать?

Периодически у каждого из нас возникает вопрос: а чтобы такого почитать?

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

Как выбрать "правильную" книгу?

Универсального рецепта не дам :) (потому что его нет), но хочется поделиться некоторыми мыслями на этот счет.

Я разделяю книги условно на две категории:
- художественная
- профессиональная

С художественной литературой обычно проблем ни у кого не возникает.

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

Что касается профессиональной литературы, то желательно найти эксперта в интересующей вас области и попросить назвать его ТОП 10 книг по данной тематике.

Если под рукой такого эксперта не оказалось - не беда, идем на сайт moikrug.ru, вводим в строке поиска интересующую нас тему (или должность эксперта, например CIO) и смотрим страницы пользователей. На страницах есть раздел "Рекомендуемые книги". Как правило это и есть тот самый ТОП книг эксперта.

Внимание! Эксперты бывают разные, внимательно ознакомьтесь с их достижениями на профессиональном поприще. CIO школы N г. Липецка звучит конечно круто, примерно как генеральный директор точки по продаже укропа у станции метро Выхино, но вряд ли вы искали эксперта именно этого уровня :)

К сожалению, существует целый пласт полезных, но не популярных книг, которые редко рекомендуют даже эксперты (опять же зависит от их уровня), но, как говорится, кто ищет, тот найдет!

Также можно воспользоваться рейтингами популярности таких сайтов как amazon.com, ozon.ru и другие.

Parallel Programming - параллельная обработка элементов коллекции

Задача: вам нужно параллельно обработать каждый элемент коллекции

Решение: используйте метод System.Threading.Parallel.ForEach для создания новой задачи для каждого элемента коллекции. Опционально можете использовать тип System.Threading.ParallelOptions для ограничения степени параллелизма при выполнении задач над элементами коллекции.

Как это работает
Статический метод Parallel.ForEach в качестве аргументов принимает коллекцию, делегат и необязательный аргумент типа ParallelOptions. Новая задача создается для выполнения задачи над каждым элементом коллекции, используя переданный делегат. Количество конкурентных задач управляется с помощью свойства ParallelOptions.MaxDegreeOfParallelism: значение -1 означает, что степень параллелизима будет определена средой выполнения, значение 1 или больше - количество задач, которые будут выполняться одновременно (значение 0 приведет к выдаче исключения).

Пример кода:

        private void PrintNumbers(int baseNumber)
        {
            for (int i = baseNumber, j = baseNumber + 10; i < j; i++)
            {
                Console.WriteLine("Число: {0}", i);
                Thread.Sleep(100);
            }
        }

        public void StartTest()
        {
            // Определяем данные, которые необходимо обработать
            int[] numbersArray = { 100, 200, 300 };

            // Конфигурируем опции
            ParallelOptions options = new ParallelOptions();
            options.MaxDegreeOfParallelism = 2;

            // Обрабатываем каждый элемент данных параллельно
            Parallel.ForEach(
                numbersArray,
                options,
                baseNumber => PrintNumbers(baseNumber)
            );
        }

Источник: "C# 2010 Recipes - A Problem Solution Approach" Allen Jones and Adam Freeman.

Предыдущая статья: "Parallel Programming - ожидания завершения задач"

Подсветка кода на blogger.com

Оригинал статьи на английском здесь.

Как добавить подсветку синтаксиса на сайте Blogger.com с помощью Alex Gorbatchev's open-source SyntaxHighlighter.

• Залогинтесь на ваш blogspot аккаунт, выберите закладку "Дизайн" и кликните "Изменить HTML."
• Сделайте резервную копию шаблона, кликнув по ссылке "Загрузить весь шаблон".
• В разметке шаблона найдите закрывающий тэг </head>. Перед ним вставьте следующий код:
  
  
  
• После строки комментария "add brushes here," добавьте языки программирования, которые вы собираетесь использовать. Для пример, я использую кисти (brushes) для Javascript, Bash, SQL, XML/HTML и C#:
  
  
  
  Полный список кистей здесь
  
• Сохраните измененный шаблон
• Теперь у вас появилась возможность подсвечивать синтаксис в блоге. Оберните ваш код тэгом <pre> и укажите кисть в атрибуте class. Пример для подсвечивания SQL кода:
  
  <pre class="brush:sql">
  SELECT *
  FROM users
  WHERE user_id = 1212;
  </pre>
 

Должно получиться следующее:

SELECT *
FROM users
WHERE user_id = 1212;

Parallel Programming - ожидания завершения задач

Задача: нужно дождаться окончания выполнения одной или нескольких задач.

Решение: используйте методы Wait, WaitAll или WaitAny класса System.Threading.Task.

Как это работает

Метод Wait вызванный у экземпляра класса Task блокирует вызывающий поток до тех пор, пока задача не завершится. Статические методы WaitAll и WaitAny принимают в качестве аргументов массив задач. Метод WaitAll блокирует вызывающий поток до тех пор, пока ВСЕ задачи из переданного массива задач не закончат выполняться. Метод WaitAny блокирует вызывающий поток до тех пор пока хотя бы одна из задач не выполнится.
Эти методы также принимают в качестве аргумента количество миллисекунд - время ожидания выполнения задачи. Если за это время задача не успела выполниться, ожидание прекращается и продолжается выполнения кода.
Свойство IsCompleted класса Task используется для определения завершения задачи.

Пример кода.
Используемые пространства имен:

using System.Threading;
using System.Threading.Tasks;

Тестовый класс:

    public class WaitTest
    {
        private int WriteDays()
        {
            string[] daysArray = {
                "Понедельник",
                "Вторник",
                "Среда",
                "Четверг",
                "Пятница",
                "Суббота",
                "Воскресенье"
            };

            foreach (string day in daysArray)
            {
                Console.WriteLine("День недели: {0}", day);
                // подвешиваем текущий поток и даем возможность отработать другим потокам
                Thread.Sleep(500);
            }

            return daysArray.Length;
        }

        private int WriteMonths()
        {
            string[] monthsArray =
            {
                "Янв", "Фев", "Мар", "Апр",
                "Май", "Июн", "Июл", "Авг",
                "Сен", "Окт", "Ноя", "Дек"
            };

            foreach (string month in monthsArray)
            {
                Console.WriteLine("Месяц: {0}", month);
                // подвешиваем текущий поток и даем возможность отработать другим потокам
                Thread.Sleep(500);
            }

            return monthsArray.Length;
        }

        private int WriteCities()
        {
            string[] citiesArray = { "Москва", "Лондон", "Шанхай", "Стокгольм", "Таллинн" };

            foreach (string city in citiesArray)
            {
                Console.WriteLine("Город: {0}", city);
                // подвешиваем текущий поток и даем возможность отработать другим потокам
                Thread.Sleep(500);
            }

            return citiesArray.Length;
        }

        public void StartTest()
        {
            // при каждом вызове StartNew запускается новая задача
            Task<int> task1 = Task<int>.Factory.StartNew(WriteDays);
            Task<int> task2 = Task<int>.Factory.StartNew(WriteMonths);
            Task<int> task3 = Task<int>.Factory.StartNew(WriteCities);

            // Так можно дождаться завершения выполнения конкретной задачи:
            //task1.Wait();

            // дожидаемся завершения всех задач:
            Task.WaitAll(task1, task2, task3);

            // Получаем результат от задач
            // При каждом вызове свойства Result, текущий поток подвисает
            // до получения результата из задачи
            Console.WriteLine("{0} дней", task1.Result);
            Console.WriteLine("{0} месяцев", task2.Result);
            Console.WriteLine("{0} городов", task3.Result);
        }
    }

Источник: "C# 2010 Recipes - A Problem Solution Approach" Allen Jones and Adam Freeman.

Предыдущая статья: "Parallel Programming - получение результата выполнения задачи"

Parallel Programming - получение результата выполнения задачи

Задача: нужно получить результат выполнения параллельно выполняющихся задач.

Решение: создайте задачи (объекты типа Task) путем вызова статического метода System.Threading.Task<>.Factory.StartNew. Используйте свойство Task.Result для получения результата выполнения ваших задач.

Примечание: Метод StartNew создает и сразу же запускает задачу на выполнение. Если вам нужно создать задачи и запустить их позже, вы можете создать экземпляры класса Task через конструктор и запустить их, используя метод Start.

Пример кода.

Используемые пространства имен:

using System.Threading;
using System.Threading.Tasks;

Тестовый класс:

    public class ReturnResultTest
    {
        private int WriteDays()
        {
            string[] daysArray = {
                "Понедельник",
                "Вторник",
                "Среда",
                "Четверг",
                "Пятница",
                "Суббота",
                "Воскресенье"
            };

            foreach (string day in daysArray)
            {
                Console.WriteLine("День недели: {0}", day);
                // подвешиваем текущий поток и даем возможность отработать другим потокам
                Thread.Sleep(500);
            }

            return daysArray.Length;
        }

        private int WriteMonths()
        {
            string[] monthsArray =
            {
                "Янв", "Фев", "Мар", "Апр",
                "Май", "Июн", "Июл", "Авг",
                "Сен", "Окт", "Ноя", "Дек"
            };

            foreach (string month in monthsArray)
            {
                Console.WriteLine("Месяц: {0}", month);
                // подвешиваем текущий поток и даем возможность отработать другим потокам
                Thread.Sleep(500);
            }

            return monthsArray.Length;
        }

        private int WriteCities()
        {
            string[] citiesArray = { "Москва", "Лондон", "Шанхай", "Стокгольм", "Таллинн" };

            foreach (string city in citiesArray)
            {
                Console.WriteLine("Город: {0}", city);
                // подвешиваем текущий поток и даем возможность отработать другим потокам
                Thread.Sleep(500);
            }

            return citiesArray.Length;
        }

        public void StartTest()
        {
            // при каждом вызове StartNew запускается новая задача
            Task<int> task1 = Task<int>.Factory.StartNew(WriteDays);
            Task<int> task2 = Task<int>.Factory.StartNew(WriteMonths);
            Task<int> task3 = Task<int>.Factory.StartNew(WriteCities);

            // Получаем результат от задач
            // При каждом вызове свойства Result, текущий поток подвисает
            // до получения результата из задачи
            Console.WriteLine("{0} дней", task1.Result);
            Console.WriteLine("{0} месяцев", task2.Result);
            Console.WriteLine("{0} городов", task3.Result);
        }
    }

Примерный результат выполнения:
День недели: Понедельник
Месяц: Янв
Месяц: Фев
День недели: Вторник
Месяц: Мар
День недели: Среда
Город: Москва
День недели: Четверг
Месяц: Апр
Город: Лондон
День недели: Пятница
Месяц: Май
Город: Шанхай
Месяц: Июн
День недели: Суббота
Город: Стокгольм
Месяц: Июл
День недели: Воскресенье
Город: Таллинн
Месяц: Авг
7 дней - это результат, полученный из задачи (!)
Месяц: Сен
Месяц: Окт
Месяц: Ноя
Месяц: Дек
12 месяцев - это результат, полученный из задачи (!)
5 городов - это результат, полученный из задачи (!)


Источник: "C# 2010 Recipes - A Problem Solution Approach" Allen Jones and Adam Freeman.

Предыдущая статья: "Parallel Programming - вступление"

Parallel Programming - вступление

С новой версией .NET Framework 4.0 корпорация Microsoft представила новую модель для написания многопоточных приложений - эта модель известна как параллельное программирование (parallel programming) и ее реализация называется Task Parallel Library. В отличие от традиционного подхода в многопоточности, где вы создаете и управляете набором потоков в вашем коде, новая модель позволяет вам сфокусироваться в первую очередь на задачах, которые вам нужно выполнить. Среда выполнения выполнит всю "грязную" работу за вас.
Основной недостаток этого подхода в том, что ваш код нацелен на задачи, которые нужно выполнять, а не на то КАК они должны выполняться. Другими словами, вы теряете полный контроль над многопоточным выполнением кода. В принципе, для большинства приложений это не критично. Но если вам нужна тонкая настройка и контроль над потоками, пользуйтесь классической многопоточной моделью.

Простейший пример выполнения нескольких задач параллельно.


Задача: нужно выполнить несколько задач (методов) параллельно.

Решение: нужно воспользоваться методом Invoke класса System.Threading.Parallel, передав в него экземпляр делегата System.Action для каждого метода, который вы хотите выполнить.

Пример кода.
Подключаем к классу следующие пространства имен:

using System.Threading;
using System.Threading.Tasks;

Тестовый класс:

    public class InvokeTest
    {
        private void WriteDays()
        {
            string[] daysArray = {
                "Понедельник",
                "Вторник",
                "Среда",
                "Четверг",
                "Пятница",
                "Суббота",
                "Воскресенье"
            };

            foreach (string day in daysArray)
            {
                Console.WriteLine("День недели: {0}", day);
                // подвешиваем текущий поток и даем возможность отработать другим потокам
                Thread.Sleep(500);
            }
        }

        private void WriteMonths()
        {
            string[] monthsArray =
            {
                "Янв", "Фев", "Мар", "Апр",
                "Май", "Июн", "Июл", "Авг",
                "Сен", "Окт", "Ноя", "Дек"
            };

            foreach (string month in monthsArray)
            {
                Console.WriteLine("Месяц: {0}", month);
                // подвешиваем текущий поток и даем возможность отработать другим потокам
                Thread.Sleep(500);
            }
        }

        private void WriteCities()
        {
            string[] citiesArray = { "Москва", "Лондон", "Шанхай", "Стокгольм", "Таллинн" };

            foreach (string city in citiesArray)
            {
                Console.WriteLine("Город: {0}", city);
                // подвешиваем текущий поток и даем возможность отработать другим потокам
                Thread.Sleep(500);
            }
        }

        public void StartTest()
        {
            // 1-ый вариант вызова:
            Parallel.Invoke(
                new Action(WriteDays),
                new Action(WriteMonths),
                new Action(WriteCities)
                );

            // 2-ой вариант вызова:
            Parallel.Invoke(
                () => WriteDays(),
                () => WriteMonths(),
                () => WriteCities()
                );

            // 3-ий вариант вызова:
            Parallel.Invoke(
                WriteDays,
                WriteMonths,
                WriteCities
                );
        }
    }

Результат выполнения:

День недели: Понедельник
Месяц: Янв
День недели: Вторник
Месяц: Фев
Город: Москва
День недели: Среда
Месяц: Мар
Город: Лондон
День недели: Четверг
Месяц: Апр
Город: Шанхай
День недели: Пятница
Месяц: Май
Город: Стокгольм
День недели: Суббота
Месяц: Июн
Город: Таллинн
День недели: Воскресенье
Месяц: Июл
Месяц: Авг
Месяц: Сен
Месяц: Окт
Месяц: Ноя
Месяц: Дек



Источник: "C# 2010 Recipes - A Problem Solution Approach" Allen Jones and Adam Freeman.

Дополнительная полезная информация: "Работа с потоками в C#"

Сто правил NASA для руководителей проектов

Руководитель проекта

Правило 1
Руководитель проекта должен посетить каждого, кто делает что-нибудь в его проекте хотя бы один раз, должен знать всех менеджеров в своём проекте (как из государственных органов, так и у субподрядчиков), а также членов команды проекта. Людям нравится, когда руководитель проекта заинтересован в их работе и лучше всего посетить их лично и увидеть самому, что они делают.
Правило 2
Руководитель проекта должен знать мотивацию участников проекта (то есть их систему премирования и штрафов, их регламенты и другие компоненты культуры этих компаний).
Правило 3
Принципы управления не изменяются. Меняются только средства. Вы по прежнему должны найти нужных для выполнения работы людей и найти путь, следуя которому они смогут выполнить её.
Правило 4
С кем бы вы не имели дело, будьте честны и справедливы. Многие области бизнеса не предоставляют слишком широкие возможности. Вы можете быть удивлены тем, насколько часто вам придётся работать с одними и теми же людьми. Пусть лучше они уважают вас, чем тащить за собой груз их недовольства вами.
Правило 5
Руководителями проектов могут быть порочные, презренные и совершенно неприятные люди. Бездушные, нерешительные копуши или болтуны – нет.
Правило 6
Подходящим руководителем проекта может быть некто, ожидающий следующего назначения или находящийся на грани неудачи. Полная безопасность не характерна для руководителя проекта.
Правило 7
Одной из проблем нового руководителя проекта является то, что все ждут от него решения своих проблем. Старым руководителям проектов старшее руководство обычно говорило «решите ваши собственные проблемы, мы вас нанимали именно для этого».
Правило 8
Текущая деятельность обычно не оставляет времени для того, чтобы вы могли думать. Вы должны выкроить время для того, чтобы понюхать розы. При вашей работе вы должны иметь время для того, чтобы понять последствия ваших действий.
Правило 9
Руководитель может не знать, как должна выполняться работа, но он знает, чего он хочет. Он лучше определит, чего он ожидает, и хочет, даже если он не знает как. Слепой лидер имеет тенденцию к движению по кругу.
Правило 10
Не все успешные менеджеры компетентны и не все потерпевшие неудачу менеджеры некомпетентны. Удача играет существенную роль в успехе или неудаче, но удача предпочитает компетентных и трудолюбивых руководителей.
Правило 11
Никогда не пытайтесь пренебрежительно относиться к кому-нибудь из участников проекта. Это плохая форма и это поставит вас на один уровень с этим человеком и, кроме того, наверняка принесёт вред проекту.
Правило 12
Не становитесь самовлюблённым настолько, чтобы не лишить себя возможности изменить свою позицию, особенно если ваш персонал говорит вам и вашей ошибке. Вы должны создать в проекте отношения, при которых ваш персонал знает, что может говорить вам о ваших неправильных решениях.
Правило 13
Руководитель, который является своим собственным системным инженером и финансовым менеджером, является тем, кто вероятно пытается сделать самому себе открытую операцию на сердце.
Правило 14
Большинство руководителей преуспевают за счёт усилий и навыков своего персонала.

Инициация проекта

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

Коммуникации

Правило 16
Совместная работа требует хороших коммуникаций и наличия системы раннего предупреждения. Руководитель проекта должен держать своих партнёров в курсе происходящего и должен быть первым, от кого они получают сведения и изменения плана. С партнёрами необходимо консультироваться до того, как события уже произойдут, даже если их участие в проекте незначительно. Руководитель проекта, который огорошивает своих партнёров, потеряет свою репутацию и будет рассматриваться как нечестный (находящийся вне системы).
Правило 17
Переговоры не самый дешёвый, но самый лучший способ понять персонал или техническую проблему как раз состоит в том, чтобы обсудить это с нужными людьми. Недостаток переговоров нужного уровня смертелен.
Правило 18
Большинство международных встреч проводятся на английском языке. Этот язык наиболее приемлем для таких участников, как американцы, англичане, итальянцы и т.д. Важно обеспечить адекватный уровень дискуссии с тем, чтобы обеспечить максимальное взаимопонимание.
Правило 19
Вы не должны допускать, чтобы вы не знали языка, принятого в области, которой вы руководите или с которыми вы связываетесь. Современный руководитель должен быть хорошо образован. Есть достаточно простые курсы, достаточные для того, чтобы изучить компьютерные проблемы, проблемы коммуникации и прочие «измы» современного мира. Вы не можете руководить, не понимая того, что говорится и пишется.

Персонал

Правило 20
Вы не можете наблюдать за всем. То, за чем вы должны наблюдать обязательно – это персонал. Люди должны знать, что вы не потерпите плохой работы.
Правило 21
Существует достаточное количество людей, более заинтересованных в процессе работы, чем в её результатах, как часто считают старые менеджеры. Последним кажется, что новое поколение более заинтересовано в форме, чем в её содержании. Главный вопрос в том, правы ли эти старые менеджеры или они только стары? Учитывайте обе возможности.
Правило 22
Хорошие технические специалисты, инспекторы качества для получения хорошего продукта важнее всяких бумаг и отчётов.
Правило 23
Источником большинства проблем являются люди, это в значительной мере можно предотвратить, если это признать. Знайте работающих в проекте людей и их реальные слабые места.
Правило 24
Некоторые работники являются трудоголиками в своей деятельности – если они двигаются в неверном направлении, они способны принести вред в короткое время. Их можно перегрузить, что может привести к их преждевременному сгоранию, и при этом сложно определить, в какой мере их загрузка создана ими самими же. Важно быть уверенными, что такие люди имеют достаточно свободного времени и что их перегрузка не превышает четверти или половины, что совершенно нормально.
Правило 25
Всегда пытайтесь обсудить внутреннюю поддержку на самом нижнем уровне. Вам нужна поддержка людей, выполняющих непосредственную работу и лучший путь её получить непосредственно в обсуждениях.
Правило 26
Если кто-то не смотрит, не спрашивает, не анализирует, то попросите его уйти.
Правило 27
Рабочее время персонала очень важно. Вы должны быть внимательны как менеджер, понимающий значение других людей и ценящий их время (то есть поручаемая работа и организуемые совещания должны быть действительно необходимы). Там, где это возможно, вы должны оградить персонал от ненужной работы (например, можно игнорировать некоторые запросы или их инициатору можно направлять отказ).
Правило 28
Люди, контролирующие работу и не помогающие её выполнять, никогда не могут точно знать, что же происходит на самом деле (вовлечение в работу есть путь к совершенству в этой области).
Правило 29
Нет большей мотивации для хорошего человека, чем предоставить ему возможности своей роли в управлении его проблемами, но даже похлопывание по спине или премия тоже достигают своей цели.
Правило 30
Некомпетентные специалисты обычно не любят демонстрировать свою работу.
Правило 31
Редко складывается так, что работу может выполнять только один человек. Так складывается в областях техники, для которых роль высокого уровня квалификации и умений относительно велика. Берегите таких специалистов, но старайтесь, чтобы их работа была закончена как можно быстрее. Выполнение работ неподходящими специалистами может потребовать в два-три раза больше времени при вероятном уровне качества ниже требуемых стандартов.
Правило 32
Обычно у людей есть причины выполнять работу так, как они это делают. Большинство людей хотят делать свою работу хорошо, и, если это не получается, скорей всего они просто не знают, как это нужно сделать или что точно от них ожидается.
Правило 33
Если у вас есть проблема, для решения которой требуется привлечение дополнительных людей, то при наборе людей бы должны действовать подобно повару, который солит пищу понемногу, чтобы не пересолить её.

Доклады и отчёты

Правило 34
В НАСА определён перечень стандартных докладов и тех должностных лиц, кто обычно ихрассматривает . Однажды настроенная, такая система будет бороться за то, чтобы продолжать существовать, так что вам остаётся максимально использовать её.
Правило 35
Количество докладов и отчётов увеличивается, но объём содержащихся в них знаний не остаётся тем же самым; поэтому все ваши диаграммы и презентации должны строиться с учётом этого. Это значит, что вы должны быть способны подготовить такой набор слайдов, который можно будет перетасовывать от одной презентации к другой.
Правило 36
Ничего не скрывайте от тех должностных лиц, которым будут направлены доклады. Их репутация и ваша – на одной линии. Не скрывайте ваши бородавки и прыщи. Никаких оправданий – устанавливайте только факты.
Правило 37
Внешние проверки обычно проводятся в самые жёсткие сроки. Поэтому поддерживайте актуальные наборы деловых и технических данных для того, чтобы иметь возможность быстро реагировать на запросы проверяющих.
Правило 38
Никогда не обрывайте ваших подчинённых публично (при посторонних, не отменяйте свои принятые ранее решения о порученной работе). Даже если вы принимаете решение об изменениях, никогда не принимайте на себя ответственность без ваших подчинённых.
Правило 39
Отчёты пишутся не для того, кто их составляет, а для того, кому они предназначены. Если тот, для кого отчет предназначен, не узнает из него ничего нового, то такой отчет неудачен.
Правило 40
Оптимальное количество участников совещания не должно превышать шесть человек. Совещания с большим количеством участников полезны только как информационные (исследования в области научного менеджмента показали, что при количестве участников более 12 человек совещания часто проходят впустую).
Правило 41
Количество отчётов обычно связано со степенью понимания дела руководством (то есть, чем меньше руководитель знает и понимает дело, тем больше отчётов он требует). В таких случаях необходимо удостовериться, что данные подготовлены в расчёте на среднего человека, немного понимающего рассматриваемые проблемы. Представляйте данные просто и не пытайтесь потрясти ничей интеллект.
Правило 42
Руководители, которые при подготовке отчётов полагаются только на бумаги, часто терпят неудачи.
Правило 43
Документы не оставляют место знаниям. Разница между тем, что отражено в документах, которые составляли на основе определённых представлений о том, что происходит, и действительным состоянием дел, может быть велика. Документы обычно статичны и быстро устаревают.
Правило 44
Если вы регулярно представляете месячные отчёты, это ещё не даёт оснований для того, чтобы опустить что-нибудь в годовом отчёте. Если бы руководство исчерпывающе знало и понимало бы ежемесячные отчёты, оно не нуждалось бы в годовых.
Правило 45
Сокращения (аббревиатуры) – это головная боль. В каждом проекте их могут быть тысячи. Это позволяет рассчитывать, что высшие руководители знают сотни таких сокращений. Используйте сокращения в презентациях осторожно, если только вы не ставите своей целью запутать всех.
Правило 46
Помните, что часто проще составить дурацкую бумагу, чем доказать, что она не нужна. Боритесь с необходимостью составления ненужных документов только тогда, когда это действительно может сэкономить значительные силы и время.

Контракты и субподрядчики

Правило 47
Руководитель проекта – не управляющий работами субподрядчиков, но должен быть их движущей силой контрактов. В вопросах, связанных с оплатой, государственные служащие обязаны удостовериться, что субподрядчик на хорошем счету, то есть в состоянии выполнить работу к нужному сроку с нужным качеством. В таком случае субподрядчики не допускают провалов, НАСА получает нужный результат и поэтому поддержка контрактов должна быть эффективной. Именно поэтому не имеющие высокой репутации субподрядчики неприемлемы для руководителей государственных проектов, так как это значит, что работы не будут выполнены.
Правило 48
Оплата контрактов – хороший инструмент, позволяющий дисциплинировать как субподрядчика, так и государственного заказчика. Это характеризует статус проекта, так же как квалификацию менеджеров обеих сторон. Для оценки состояния контрактов следует использовать систему количественной оценки управления проектом. Последовательно демонстрируемые неважные показатели проекта требуют вмешательства высшего руководства для того, чтобы выявить их причину. Последовательно демонстрируемые хорошие показатели, совместимые с системой оценки хода проекта, говорят о хорошем уровне управления проектом. Но если система показателей оценки контрактов не соответствует системе оценки проекта, высшее руководство обязано выяснить, почему это происходит.
Правило 49
Моральный уровень персонала подрядчика важен для руководителя государственного проекта. Точно так же, как вы не хотели бы купить изготовленный злыми и невнимательными служащими автомобиль, вы не захотите покупать аппаратуру комплекса управления полётом у немотивированных людей. Вы должны играть активную роль в мотивации всего вовлечённого в проект персонала.
Правило 50
Быть в дружеских отношениях с субподрядчиком прекрасно, но дружеские отношения с субподрядчиком – подвергают опасности вашу объективность.
Правило 51
Помните, что ваш субподрядчик имеет тенденцию иметь прямые отношения с вашим персоналом. Каждый ваш служащий стоит по крайней мере одного человека на контракт в год.
Правило 52
Субподрядчики имеют тенденцию соизмерять правительственного партнёра со своими усилиями в проекте. Если они будут относиться к вам пренебрежительно, они будут использовать в вашем проекте из своих специалистов и служащих самых слабых.
Правило 53
Субподрядчики обычно хорошо относятся к заказчику, который уделяет внимание их работе, но плохо – к тем из заказчиков, которые пытаются непрерывно контролировать их деятельность. Основное правило здесь звучит так: клиент всегда прав, но затраты возрастут, если заказчик всегда будет настаивать на том, чтобы всё делалось в соответствии с его представлениями, вместо того, как это запланировал субподрядчик. Основное правило выглядит так: никогда не изменяйте планы субподрядчика, если только они не совсем плохи и не вызовут значительного роста расходов (лучшее – враг хорошего).
Правило 54
По отношению к слабому руководителю проекта в промышленности есть только одно хорошее решение – избавиться от него как можно быстрее. Можно сказать, что основная задача руководителя проекта в промышленности – доставлять удовольствие заказчику. Убедитесь, что те, кто работает с вами, понимает, что выполнить работу в срок, в рамках бюджета и с высоким качеством – значит доставить вам удовольствие.

Инженеры и учёные

Правило 55
Переделки в инженерных работах – обычное явление. Эта работа по своему характеру часто напоминает разгадывание загадок или блуждание в лабиринте. Старайтесь добиваться применения как можно более простых инженерных решений.
Правило 56
Первые признаки проблем в области инжиниринга - отставание от графика и отклонение кривой нарастания затрат. Инженеры узнают о том, что они находятся в центре проблем последними. Они рождены оптимистами.
Правило 57
В проекте может использоваться много ресурсов. Существует пять или десять системных инженеров, включая всех субподрядчиков и разработчиков. Это мощные ресурсы против имеющихся у вас проблем.
Правило 58
Многие менеджеры только на том основании, что в их проектах учёные подчинены им, забывают о том, что учёные и их заказчики имеют во много раз более лёгкий доступ к высшему руководству, чем сами эти менеджеры.
Правило 59
Большинство учёных ведут себя очень рационально, пока вы не подвергаете опасности их шансы на проведение их эксперимента. Они будут продолжать работать с вами, если будут уверены, что вы говорите им правду. Это относится и к сокращению их планов.

Аппаратное обеспечение

Правило 60
В космическом бизнесе практически нет случаев возврата запущенных ранее блоков. Люди, которые создают некий блок, не могут видеть запущенный ранее предыдущий блок. Вероятны небольшие изменения (возможно, даже большие изменения), вероятны изменения среды, в которой предстоит работать блоку, испытывающий блок персонал, в большинстве случаев не будут понимать принцип работы блока или испытываемого оборудования.
Правило 61
Большая часть оборудования изготавливается не так, как планировал конструктор. Это связано с размещением оборудования, плохим пониманием конструктивных решений или с плохим пониманием спецификации оборудования.

Компьютеры и программное обеспечение

Правило 62
Не применять современные технологии, в том числе и компьютерные системы – большая ошибка. Но забывать о том, что компьютеры только моделируют мышление – ещё большая ошибка.
Правило 63
Программное обеспечение не перекрывает всех параметров аппаратной части (меняются требования, высок процент стоимости полётов, требуются процедуры подтверждения и т.д.). Дополнительная особенность заключается в необходимости поиска возможных ошибок. То есть необходимо, чтобы сначала отработала основная система, после чего могут начаться звонки и свистки. Никогда не отказывайтесь от уже работающей версии программного обеспечения, даже если весь остальной мир будет утверждать, что более новая версия программного обеспечения работает. Это совершенно необходимо, чтобы иметь планы на случай непредвиденных обстоятельств.
Правило 64
Знания часто пересматриваются на основе результатов моделирования или испытания, но модели компьютеров могут скрывать недостатки, не последними из которых являются неверные исходные данные.
Правило 65
В старые времена инженеры имели практический опыт, технические специалисты понимали, как работает электроника и что нужно для того, чтобы она заработала. Знали это и схемотехники, но сейчас наверняка это знает только компьютер и он не рассказывает об этом.

Старшие менеджеры, руководители программ и те, кто над ними

Правило 66
Не следует предполагать, будто вы знаете, почему высшее руководство предпринимает нечто. Если вы чувствуете, что должны это знать, спросите. Вы получите неожиданные ответы, которые удивят вас.
Правило 67
Знайте своих руководителей – некоторые любят хорошую шутку, другие любят шутить только сами.
Правило 68
Помните, что ваш руководитель имеет право принимать решения. Даже если вы уверены, что это неверно, скажите ему, что вы думаете о его решении и, если он будет продолжать настаивать, выполните его решение и сделайте всё возможное для получения успешного результата.
Правило 69
Никогда не предлагайте своему руководителю принять решение, которое вы могли бы принять сами. Исходите из того, что у вас есть необходимые для принятия решения полномочия, если только вам не известен документ, недвусмысленно запрещающий это.
Правило 70
Вы и ваш руководитель программы должны работать как одна команда. Руководитель программы – ваш адвокат в главной штаб-квартире НАСА и он должен быть вхож к лицам, принимающим решения, помогая вашим усилиям получить доступ к этим лицам.
Правило 71
Знайте, кто принимает решения на уровне программы. Это может быть человек извне, который имеет ухо в конгрессе или в администрации или у заместителя руководителя администрации, учёный, кто-то в руководстве – кто бы он ни был. Попытайтесь установить с ним контакт на формальном или неформальном уровне.

Планирование, бюджетирование и оценки

Правило 72
Сегодня нужно поддерживать необходимый уровень, быть в пределах бюджета и графика. Странно, но все соответствуют этому до тех пор, пока придерживаются основных установленных правил вроде кривой нарастания затрат и графика.
Правило 73
Большая часть прошлых проектов выполнялись с превышением бюджета из-за неточных оценок, а не из-за ошибок. Получение более высоких оценок не снизит затраты, но улучшит деловую репутацию НАСА. На самом деле с высокой вероятностью можно считать, что более высокие оценки приведут к росту затрат и росту прибылей промышленности, если только стоимость контрактов не будет уменьшена, чтобы отразить снизившиеся риски промышленных компаний. Хорошая репутация совершенно необходима в современной обстановке.
Правило 74
Все проблемы можно разрешить во время, если в вашем графика есть достаточные резервы времени на непредвиденные обстоятельства – если это не так, ваше место займёт другой руководитель проекта.
Правило 75
Старая НАСА покровительствовала лимитам на технологии и науку; следовательно, её не волновали отставания от графика или превышения бюджета. В новой НАСА все проекты имеют фиксированную цену; следовательно, запрос на перенос сроков становится смерти подобен.
Правило 76
Знайте ресурсы своего центра, если возможно, и других центров тоже. Другие центры, если у них есть ресурсы, обычно с готовностью помогают. Удивительно, как много важной помощи можно получить с помощью простой просьбы.
Правило 77
Любая информация о проекте, кроме бюджета, до представления её президентом в конгресс, вероятно, не является секретной – так не делайте из неё секрета. Каждый сможет принять более правильное решение, если сможет видеть полную картину, поэтому не скрывайте ничего.
Правило 78
Программы НАСА выполняются за счёт бюджетных фондов – и не финансируются из других источников (то есть, никогда не требуйте от других программ или работ НАСА, чтобы они поделились с вами финансированием). Продайте что-либо из имеющегося у вас в пользу своей программы.
Правило 79
Следующий год – это всегда год с нормальным финансированием и графиком работ. Такой следующий год наступит на пятидесятом году вашей карьеры.

Заказчик

Правило 80
Помните, кто у вас заказчик и каковы его цели (то есть согласуйте с ним существенные изменения, которые вы хотите предпринять).

Инструкции НАСА по управлению

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

Принятие решений

Правило 82
Неправильное решение, принятое ранее, может быть пересмотрено позднее. Правильное решение, принятое слишком поздно, ничего не может изменить.
Правило 83
В некоторых случаях лучшим выходом является ничего не предпринимать. Иногда это – самое лучшее, чем можно себе помочь. Во многих случаях от вас требуется только слушать. Вы можете быть руководителем высокого ранга, но если вы постоянно решаете чьи-то проблемы, то это значит, что вы работаете на этого человека.
Правило 84
Никогда не принимайте скоропалительных решений, ориентированных на внешний эффект. Ознакомьтесь с действительным состоянием оборудования, с действительно доступной информацией. Слишком много времени теряется людьми, которые заботятся о внешней стороне вместо того, чтобы заняться причинами.

Профессиональная этика и порядочность

Правило 85
Порядочность означает, что ваши подчинённые доверяют вам.
Правило 86
Даже делая какой-нибудь пустяк, важно помнить, для кого вы работаете. Давить на слабые места вашего руководителя невыгодно для вас в долгосрочном плане.

Управление проектом и рабочая группа

Правило 87
Для успешного выполнения проекта необходима рабочая группа. Большая часть рабочих групп имеет не руководителя, а наставника, но именно продолжает оставаться тем лицом, который вызывает определённые действия.
Правило 88
Никогда не предполагайте, что некто знает нечто или сделал нечто, кроме того, о чём вы его просили; даже очевидное может быть пересмотрено или игнорировано при случае, особенно при напряжённой работе.
Правило 89
Тот, кто говорит, что нищие не могут выбирать, плохо разбирается в управлении проектами. В большинстве ситуаций лучше полагаться на удачу, чем на слабую поддержку.
Правило 90
Мозаику трудно сложить по одному её элементу и поэтому не удивляйтесь, что члены команды на основании анализа данных будут приходить к неверным заключениям.
Правило 91
Помните, что Президент, Конгресс, Административное бюджетное управление, высшие руководители, ваши заказчики все очень заняты работой. Всё, что вы сможете сделать для них – доставить им радость.

Переговоры и предотвращение неудач

Правило 92 В случае неудачи:

• Восстановите цепь событий и отразите в ней всё, что вам известно.
• Рассмотрите известные факты. Проверьте каждую гипотезу о них.
• Не надо выдавливать из фактов выводы в попытках восстановить сценарий.
• Не делайте заключений слишком быстро. Будьте уверены, что любые отклонения от нормального хода проекта объяснены.
• Помните, что любое неправильное объяснение – только пролог к следующей неудаче.
• Знайте, когда следует остановиться.

Правило 93
Думайте, что неудачи – это выученные на будущее уроки. Иногда правильно думать, что это только выученные уроки. Старайтесь повторять их во время работы.
Правило 94
Ошибка – это совершенно нормальная вещь, а вот неудача – нет. Неудача – это ошибка, которую вы не смогли исправить; следовательно, всегда разрабатывайте планы и альтернативные решения для аналогичных ситуаций или планы для ситуаций с высокими рисками.
Правило 95
История представляет собой пролог. Не было проекта, в котором вопреки квалификации и опыту не имел проблем в своих компонентах. Время и готовность реагировать являются единственной защитой.
Правило 96
Опыт может быть очень полезным, но практическая проверка ещё лучше. Некоторые знания никогда не срабатывают, тогда как испытания и проверки всегда показывают то, что хотят.
Правило 97
Не бойтесь неудач или вы никогда не добьётесь успеха, но всегда совершенствуйте свою квалификацию. Часть такой квалификации заключается в том, чтобы знать, кто может помочь в каком случае.
Правило 98
Одним из достоинств НАСА в раннем периоде её существования был тот факт, что если некто что-то знал, то мы были абсолютно уверены, что он может быть неправ.
Правило 99
Избыток оборудования может быть фикцией. Мы придерживались такого подхода, при котором всё созданное должно быть идентично, так что если где-то происходил отказ, то он проявлялся и в других местах. Будьте уверены, что всё оборудование отработано настолько, как будто бы его единственный образец обеспечивает успех всей миссии.
Правило 100
Никогда не оправдывайтесь; вместо этого представьте план действий, которые необходимо предпринять.

О документе

Документ подготовлен Джерри Мэддоном (Jerry Maddon), ассоциированным директором Директората полётов Годдартовского центра космических полётов NASA. Джерри собрал эти драгоценности мудрости за много лет из разнообразных источников. Они были отредактированы Родом Стюартом (Rod Steward) из Mobile Data Service из Хантсвилла в Алабаме (Huntsvill, Alabama),. 1 января 1995 года. Обновлено 9 июля 1996 года. Переработано и отформатировано Оливером Ф. Леманом (Oliver F. Lehmann, Ismaning, Germany.
Источник: EasyTask
Контакт: Шерман Джоб (Sherman Jobe) Sherman.jobe@msfc.nasa.gov, (205)-544-3279
Перевод: В. Куперштейн
Редакция: В. Богданов

Рейтинг деловой литературы от Harvard Business Review

Рейтинг деловой литературы от Harvard Business Review от 21.08.2011:

Глеб Архангельский
Тайм-драйв

Стивен Р. Кови
7 навыков высокоэффективных людей. Мощные инструменты развития личности

Джим Коллинз
От хорошего к великому. Почему одни компании совершают прорыв, а другие нет

Теодор Драйзер
Трилогия «Финансист», «Титан», «Стоик»

Элияху М. Голдрат, Джефф Кокс
Цель: процесс непрерывного совершенствования

Ричард Брэнсон
Теряя невинность

Кьелл А. Нордстрем, Йонас Риддерстрале
Бизнес в стиле фанк. Капитал пляшет под дудку таланта

Глеб Архангельский
Организация времени: От личной эффективности к организации

Айн Рэнд
Атлант расправил плечи

Джек Траут, Эл Райс
Маркетинговые войны

Ли Якокка
Карьера менеджера

У. Чан Ким, Рене Моборн
Стратегия голубого океана

Майкл Портер
Конкурентное преимущество. Как достичь высокого результата и обеспечить его устойчивость

Джек Уэлч, Джон Бирн
Джек. Мои годы в GE

Джим Коллинз, Джерри Поррас
Построенные навечно. Успех компаний, обладающих видением

Николо Макиавелли
Государь

Питер Сенге
Пятая дисциплина. Искусство и практика самообучающейся организации

Карл Сьюэлл, Пол Браун
Клиенты на всю жизнь

Томас Дж. Питерс
Представьте себе! Превосходство в бизнесе в эпоху разрушений

Джек Траут
Сила простоты

Манфред Кетс де Врис
Мистика лидерства. Развитие эмоционального интеллекта

Сэм Уолтон, Джон Хьюи
Сделано в Америке. Как я создал Wal-Mart

Питер Ф. Друкер
Энциклопедия менеджмента

Питер Ф. Друкер
Задачи менеджмента в XXI веке

Эрих Фромм
Иметь или быть

Клейтон М. Кристенсен
Дилемма инноватора. Как из-за новых технологий погибают сильные компании

Малкольм Гладуэлл
Переломный момент. Как незначительные изменения приводят к глобальным переменам

Майкл Льюис
Покер лжецов

Эд Майклз, Хелен Хэндфилд-Джонс, Элизабет Экселрод
Война за таланты

Дэвид Майстер
Управление фирмой, оказывающей профессиональные услуги

Джек Траут
Позиционирование: битва за узнаваемость

Клаус Кобьелл
Мотивация в стиле ЭКШН. Восторг заразителен

Джек Траут, Эл Райс
22 непреложных закона маркетинга: Нарушайте их на свой страх и риск!

Джон Шоул
Первоклассный сервис как конкурентное преимущество

Фрэнсис Фукуяма
Доверие: социальные добродетели и сотворение благоденствия

Джон П. Коттер
Лидерство Мацуситы. Уроки выдающегося предпринимателя ХХ века

Майкл Уоткинс
Первые 90 дней: ключевые стратегии успеха для новых лидеров на всех уровнях

Томас Дж. Питерс, Роберт Х. Уотерман-мл.
В поисках совершенства. Уроки самых успешных компаний Америки

Джек Траут, Стив Ривкин
Дифференцируйся или умирай! Выживание в эпоху убийственной конкуренции

Пол Хейне
Экономический образ мышления

Майкл Хаммер, Джеймс Чампи
Реинжиниринг корпорации. Манифест революции в бизнесе

Говард Шульц
Влейте в нее свое сердце

Лу Герстнер
Кто сказал, что слоны не умеют танцевать?

Джозеф О'Коннор, Иан Макдермотт
Искусство системного мышления

Харви Маккей
Как уцелеть среди акул

Джон П. Коттер, Дэн С. Коэн
Суть перемен. Невыдуманные истории о том, как люди изменяют свои организации

Клотер Рапай
Культурный код: как мы живем, что покупаем и почему

Кьелл А. Нордстрем, Йонас Риддерстрале
Караоке-капитализм. Менеджмент для человечества

Джордж Колризер
Не стать заложником: сохранить самообладание и убедить оппонента

Томас Гэд
4D брэндинг: взламывая корпоративный код сетевой экономики

Нил Рекхэм
Проактивные продажи

Томас Дж. Питерс
Человек-бренд

Йеспер Кунде
Уникальность теперь... или никогда. Книга о корпоративной религии

Патрик Бервайз, Шон Михан
Просто лучше. Завоевывать и удерживать потребителей, предоставляя самое существенное

Гэри Хамел, Коимбаторе К. Прахалад
Конкурируя за будущее

Питер С. Пэнди, Роберт П. Ньюмен, Роланд Р. Кэвенег
Курс на Шесть Сигм. Как General Electric, Motorola и другие ведущие компании мира совершенствуют свое мастерство

Томас Дж. Питерс
Профессиональная сервисная фирма

Джерард Теллис, Питер Голдер
Воля и видение. Как те, кто приходит позже остальных, в итоге заправляют рынками

Джеймс Стюарт
Шайка воров с Уолл-Стрит

Томас Дж. Питерс
Проект

Дэвид Аакер
Бренд-лидерство

Дэниел Пинк
Нация свободных агентов

Philip Rosenzweig
The Halo Effect…and the Eight Other Business Delusions That Deceive Managers (Ф. Розенцвейг. «Эффект гало и восемь других бизнес-иллюзий, которые обманывают менеджеров»)

Томас Фридман
Плоский мир. Краткая история XXI века

Чарльз Хенди
Слон и блоха: Будущее крупных корпораций и мелкого бизнеса

Джордж Сток-мл., Роб Лахенауэр
Жесткая игра

Роджер Камрасс, Мартин Фарнкомб
Алхимия корпорации. Как реформировать структуру бизнеса в соответствии с реалиями завтрашнего дня

Александр Бард, Ян Зодерквист
Нетократия. Новая правящая элита и жизнь после капитализма

Ричард Флорида
Креативный класс: люди, которые меняют будущее

Майк Вудкок, Дэйв Фрэнсис
Раскрепощенный менеджер

Брайан Бурроу, Джон Хельяр
Варвары у ворот. История падения RJR Nabisco

Малкольм Уорнер, Морген Витцель
Виртуальные организации. Новые формы ведения бизнеса в XXI веке

Фрэнсис Фукуяма
Сильное государство. Управление и мировой порядок в XXI веке

Роберт Г. Хагстром
Уоррен Баффет. Как 5 долларов превратить в 50 миллиардов. Стратегия и тактика великого инвестора

Майкл Льюис
Новейшая новинка. История Силиконовой долины

Джеральд Надлер и Шозо Хибино
Мышление прорыва

Патрик Диксон
Стратегическое моделирование будущего
 

Прокрастинация

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

Читать о прокрастинации на википедии.

Как правильно задавать вопросы?

"Как правильно задавать вопросы"

Eric Steven Raymond

Статья в первую очередь для разработчиков, периодически обновляется.

Научитесь программировать за десять лет

Очень интересная и полезная статья "Научитесь программировать за десять лет". Хоть она и старая, но содержит ряд фундаментальных выкладок.

Скрипт поиска строки по всей базе MySQL

Коллеги попросили помочь написать для них скрипт, который бы позволял искать во всех текстовых полях MySQL базы заданную строку (например IP адрес).
Ниже привожу результат своих трудов.
Скрипт написан и протестирован для версии MySQL 5.1.x и на других версиях может не работать (!)

USE testdb;
SET @table_schema = 'testdb';

DROP PROCEDURE IF EXISTS Scan;

DELIMITER //
CREATE PROCEDURE Scan(IN searchString varchar(50))
BEGIN
    DECLARE done INT DEFAULT FALSE;
    DECLARE tableName VARCHAR(64);
    DECLARE tablesCursor CURSOR FOR
        SELECT
            table_name
        FROM
            information_schema.tables
        WHERE
            table_type = 'BASE TABLE'
            AND table_schema = @table_schema;

    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

    OPEN tablesCursor;

tablesCursorLoop: LOOP
    FETCH tablesCursor INTO tableName;
    IF done = TRUE THEN LEAVE tablesCursorLoop; END IF;

    CALL ScanColumns(tableName, searchString);

    END LOOP tablesCursorLoop;
    CLOSE tablesCursor;
END//


DROP PROCEDURE IF EXISTS ScanColumns;
CREATE PROCEDURE ScanColumns(
    IN tableName varchar(64),
    IN searchString varchar(50))
BEGIN
    DECLARE done INT DEFAULT FALSE;
    DECLARE columnName VARCHAR(64);

    DECLARE columnsCursor CURSOR FOR
        SELECT
            column_name
        FROM
            information_schema.columns
        WHERE
            table_schema = @table_schema
            AND table_name = tableName;


    DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;

    OPEN columnsCursor;
columnsCursorLoop: LOOP
    FETCH columnsCursor INTO columnName;
    IF done = TRUE THEN LEAVE columnsCursorLoop; END IF;

    SET @fromWhere = CONCAT(
        ' FROM ',
        tablename,
        ' WHERE ',
        columnName,
        ' like "',
        searchString,
        '"'
    );

    SET @exists = CONCAT(
        'SELECT * ',
        @fromWhere
    );

    SET @stmtQuery = CONCAT(
        'SELECT CONCAT("Found ", count(*), " at ',
        tablename,
        '.',
        columnName,
        '") as " " ',
        @fromWhere,
        ' AND EXISTS (',
        @exists,
        ')'
    );


    PREPARE stmt FROM @stmtQuery;
    EXECUTE stmt;
    DEALLOCATE PREPARE stmt;

    END LOOP columnsCursorLoop;
    CLOSE columnsCursor;
END//

DELIMITER ;



CALL Scan("1.2.3.4");


DROP PROCEDURE IF EXISTS Scan;
DROP PROCEDURE IF EXISTS ScanColumns;

Алгоритм сортировки иерархических данных по алфавиту с учетом вложенности

Эта заметка будет интересна людям, которым приходиться работать с классификатором адресов Российской Федерации, сокращенно КЛАДР (подробнее...).

В КЛАДР у каждого адресного объекта есть уникальный код, в котором помимо прочего хранится информация о положении объекта во всей иерархии адресных объектов.

Код представляет набор цифр, разбитых на разряды.

Встала задача представить данные из КЛАДР в следующем виде:

Т.е. вывести их в отчет по алфавиту, сохраняя порядок вложенности в иерархии адресных объектов.

Был создан класс, описывающий сущность, выводимую в отчет:

public class AddressObjectGraph : IComparable
в этом классе был объявлен метод ToSortString:
        public string ToSortString()
        {
            // пробелы и запятые нужны лишь для наглядности,
            // в Release версии их можно убрать
            string sortFullName = string.Format(
                "{0}, {1}, {2}, {3}, {4}, {5}",
                RegionName + " " + RegionCode,
                AreaName + " " + AreaCode,
                CityName + " " + CityCode,
                PlaceName + " " + PlaceCode,
                StreetName + " " + StreetCode,
                HouseName + " " + HouseCode
            );
            return Regex.Replace(sortFullName, @"\s+", " ", RegexOptions.None);            
        }

Этот метод будет выводить информацию об объекте в следующем виде:
Тверская обл 69, Зубцовский р-н 010, 000, Борки д 036, Молодежная ул 0001, 0000

Также реализуем метод CompareTo:

        public int CompareTo(object obj)
        {
            var aoGraph = (AddressObjectGraph) obj;
            return this.ToSortString().CompareTo(aoGraph.ToSortString());
        }

Чтобы получить требуемый результат, у коллекции экземпляров типа AddressObjectGraph вызываем метод Sort, например:

var result = addressObjectGraphs.Sort();

Преобразование результирующей коллекции в требуемому виду - дело техники.

Взаимодействие с веб службами и пересекающимися типами данных

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

Необходимо было работать с обоими экземплярами этих типов на клиентской стороне, не зная о их конкретной принадлежности к той или иной службе.

Решение было довольно простым, но раз оно вызвало вопросы, решил его опубликовать.

Ключевые слова: partial классы, интерфейсы, dynamic.

Например, у нас есть служба WebService1, у которой метод GetCustomer возвращает экземпляр типа Customer.
Пример кода службы:

public class WebService1 : WebService {

    [WebMethod]
    public Customer GetCustomer(int id) {
        return new Customer
        {
            Id = id,
            Name = "test"
        };
    }
}

Описание типа Customer на стороне службы:

public class Customer
{
    public int Id { get; set; }

    public string Name { get; set; }

    public Customer()
    {
    }
}

 И есть служба WebService2 с точно таким же методом и типом возвращаемого значения.

Первый вариант решения.

Если вы используете .Net Framework 4.0, то можете воспользоваться утиной типизацией с помощью типа dynamic.
Например:

dynamic dynamicCustomer1 = service1.GetCustomer(1);
DoWork(dynamicCustomer1);

...

private void DoWork(dynamic customer)
{
     Console.WriteLine(customer.Name);
}

Второй вариант решения.

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

namespace WebServiceClient
{
    public interface ICustomer
    {
        int Id { get; set; }
        string Name { get; set; }
    }
}

namespace WebServiceClient.WebService1
{
    public partial class Customer : ICustomer
    {
    }
}

namespace WebServiceClient.WebService2
{
    public partial class Customer : ICustomer
    {
    }
}

...

Использование:

ICustomer customer1 = service1.GetCustomer(1);
DoWork(customer1);

...

private void DoWork(ICustomer customer)
{
       Console.WriteLine(customer.Name);
}

Запорный механизм сливного бачка унитаза - чиним сами

Что делать, если потек сливной бачок?

Вводная статья:
http://www.masterovoi.ru/statya-67.html

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

В Leroy Merlin (Леруа Мерлин) был куплен запорный механизм французской фирмы S.A.S. (на фото):

 

Резьба присоединения к водопроводу G1/2".

Плюсы:
- тихий
- быстрый набор воды

Минусы:
- относительно малый объем набираемой воды
- относительно высокая стоимость (около 650 рублей)

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

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

Процесс установки клапана прост:
1) перекрываем воду
2) разводным ключом откручиваем гайку подводящего шланга
3) тем же ключом откручиваем гайку старого клапана
4) устанавливаем новый клапан и собираем в обратной последовательности
5) постепенно подаем воду и смотрим за подтеками воды в местах соединения

Звенигородский филиал Московского областного бюро технической инвентаризации

Съездил в субботу в Звенигородский филиал Московского областного бюро технической инвентаризации. Пугали длинными очередями. В 9 часов утра я был единственным посетителем. Отличный персонал. Помогли в решении проблем. За что им большое спасибо.

Т.к. Яндекс выдает немного некорретную информацию, опубликую ссылки на актуальные источники.

Официальный сайт МОБТИ:
http://www.mobti.ru/

Поиск филиалов:
http://www.mobti.ru/filialy
в форме поиска вводите "Звенигород" и получаете подробную информацию о филиале.

Первое сообщение

Хорошая погода и настроение подвигли меня на создание собственного блога...

О чем?

Обо всем, что происходит в окружающей меня жизни...

Зачем?

Многие великие люди вели дневники. Решил продолжить традицию :)