Невыполнимая миссия

Чтобы чего-то добиться фирма должна иметь и осознавать некую миссию, которая отлична от простого зарабатывания денег. Деньги должны быть лишь следствием выполнения миссии. Например, поставить персональный компьютер каждому голодному, или проиндексировать всё, что шевелится, или создать лучшую программу в своей нише, или дать каждой семье отдельную квартиру к 2000 году. Это не слоган, типа "измени жизнь к лучшему". Слоган - это бессмысленная рекламная херня, работающая через подсознание. Миссия же - вполне сознательно сформулированая цель. Если миссии нет, её начинают заменять слоганы и процесс становится самоцелью. Начинаются всякие "software is about collaboration". Collaboration - средство, инструмент, но вовсе не цель. Начинаются всякие шатания, типа зачем что-то делать, давайте лучше работать с пользователями, или давайте вложим деньги куда нибудь, может нам купить кого-нибудь. Начинаются игры в деятельность: cмотрите, у них какая штука, мы тоже такую сделаем, будет лучше настоящей. Все компании добившиеся чего-то имель неденежную цель, деньги приходили потом, когда эта цель создавала новый рынок. Компании без цели - зомби, которые существуют только за счёт инерции рынка. Они уже ничего нового не создают, но выискивают свежие ростки и немедленно пожирают их, постепенно превращая индустрию в пустыню. P.S. Навеяно посещением "standup meeting".

Kangaroo Farm

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

Vantage Bridge Panorama

360° panorama: Vantage Bridge across the Columbia River.

Microsoft about Vista

> Windows Vista is doing a lot more than Windows XP, and it requires resources to conduct these tasks. В этом то и проблема, что она делает больше. Мне не надо ничего из этого "делания", я бы предпочёл, чтобы она "делала" меньше, ничего не делала. Всё, что хочется от операционной системы - это возможности выполнять нужные мне программы и работать с железом. Идеально - это когда OS не видно, когда совершенно не ощущается, что она что-то "делает", когда просто "всё работает". Я обычно трачу усилия на то, чтобы выкинуть что-то из OS, остановить ненужные сервисы, деинсталировать ненужные программы, а поставить другие, те которые я выбрал, которые обладают нужной мне функциональностью. Последний пал Explorer (причём "пал" буквально), в результате я заменил стандартный shell на bblean, чем и доволен. Фактически это привело к тому, что больше нет на экране видимых окон, принадлежащих Windows. Нет вообще.

Фраза из разговора

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

В Spokane всё спокойно

Водопад в Spokane. Это город на восточной границе штата. Через весь город протекает река с одноимённым названием, которая по случаю наступившей жаркой погоды наполнена до краёв, бурлит и клокочет. Над этим буйством стихии протянуты навестные мостики и канатная дорога. Брызги долетают до мостика и приятно освежают.

Выбор домашнего сервера

За несколько лет у меня накопилась куча железок, управляющих домашней сетью. Это два четверть-гиговых Netdisk-а, один NAS с полугигабайтным MyBook, роутер и ещё один дополнительный свитч. Из устройств есть web-камера и DVD плейер, умеющий показывать фильмы с сетевого диска. Есть ещё несколько внешних дисков с бакапами разной свежести, лежащие по шкафам. Зрелище перепутанных проводов и блоков питания приводит меня в ужас. Хочется немного уменьшить этот бардак, собрав диски в один корпус и тем самым уменьшить количество проводов. Сейчас есть пара интересных железяк от HP. Во первых это MediaSmart сервер, работающий под WHS и во вторых MediaVault, который и по размеру и по цене тянет на половинку первого, и который работает под Линуксом. Первый основан на гигагерцовом процессоре AMD, второй на дохленьком полугигагерцовом ARM-е. Почитал я спецификации и всё бы хорошо в первом, если бы не цена и не WHS. Как-то не хочется сервер под windows, мне надо, чтобы работало и с Mac-ом и с Linux-ом. Да и функциональный набор WHS кажется довольно неприменимым. Нет, совсем не вдохновляет. С другой стороны, железяка явно пошустрее и места для дисков в ней больше. Если бы первую машинку да с софтом от второй, да подешевле на пару сотен (как раз стоимость WHS, наверное). Пробовал их кто-нибудь? Интересны отзывы.

Google calculator

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

pi*(3mm^2) in inch^2: pi * (3 (mm^2)) = 0.0146084351 inch^2

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

Я когда увидел, попробовал и мне очень понравилось. Я когда-то тоже делал похожую штуку. А потому знаю где лежат одни грабли. И заглянув в заветное место увидел грабли в целости и сохранности. Вот они. Но Гугл зделал их ещё занятнее.

(0 Celsius - 0 Celsius) in Celsius: (0 degree Celsius) - (0 degree Celsius) = -273.15 degrees Celsius
0 Celsius + 0 Celsius: (0 degree Celsius) + (0 degree Celsius) = 273.15 degrees Celsius
0 Celsius *3: (0 degrees Celsius) * 3 = 546.3 degrees Celsius

Собственно, объяснение простое, но сначала ещё один пример:

0 Celsius - 0 Celsius: (0 degrees Celsius) - (0 degrees Celsius) = 0 kelvin

Гугл не умеет работать с размерностями со смещённым нулём. Для абсолютных единиц типа температуры бывают шкалы, гне нуль смещён. Например, температура Кельвина - абсолютная, а Цельсия и Фаренгейта - относительные. Вычитая относительные величины, скажем градусы Цельсия, мы получаем новую размерность - интервал температуры в градусах Кельвина или Цельсия. Очевидно, что переводя интервал в градусы Цельсия не надо прибавлять смещение в 273 градуса. Этим интервал отличается от значения температуры.

Сумма относительных температур должна оставаться в тех же единицах. Т.е. не надо два раза прибавлять смещение. Надо сначала сложить, а затем уже преобразовать размерности. Либо рассматривать одно из слагаемых как интервал, добавляемый к абсолютной величине, что математически то же самое.

В принципе, не очень часто приходится иметь дело со смещёнными размерностями. Температуры да шкалы времени, и, кажется, всё. Так что калькулятор вовсе не плох. Однако с температурами они прокололись. Слишком много сил ушло на попугаев.

Никто не знает, как Гуглу баг зафайлить?

Куда их совать-то?

Та же проблема, что и в анекдоте про свечки, существует в программировании и особенно в ООП языках. Допустим есть у нас набор объектов, скажем драйверы разных графических адаптеров. И другой набор объектов, скажем графические примитивы: линии, окружности, многоугольники. И решили мы нарисовать одно на другом. И написали для этого код. Всё уже почти работает, но перед нами встала архитектурная проблема: куда засунуть метод? В C#, например, функция должна быть в классе. Можно определить, конечно, класс с одним (или несколькими) статическим методами, но заклюют за недостаток архитектурности. Можно засунуть в графический примитив. Сделать у каждого метод Draw. А можно наоборот, в драйвере сделать виртуальные DrawLine и DrawCircle. Оба решения имеют недостатки. Например, примитивы могут быть вообще не классами, а структурами и методы рисования на конкретного вида устройствах там создают ненужные зависимости. А драйверы потому и драйверы, что не содержат всякой высокоуровневой логики. Надо сделать визитора, скажут прочитавшие Design Patterns или wrappers для примитивов, или ещё один уровень поверх драйверов, и понеслось. Что интересно, раздумья эти с точки зрения выполнения кода не очень интересны, код всё равно будет один и тот же. Это скорее предмет для бурного обсуждения на API review meeting. Что наводит на мысль, что это вообще ненужное размышление. Это плата за ООП и его упрощённую модель, когда метод принадлежит только одному классу. Логически у нас есть операция нарисовать одно на другом и некоторая матрица кодов, которые выбираются исходя из некоторых условий. Старый С-программист сделал бы функцию a la printf с форматной строкой и большим switch внутри и не был бы сильно неправ. Компьютер бы полюбил такой код за компактность, но архитект бы поморщился от такой примитивности и неархитектурности. Независимый С++-программист просто написал бы набор функций. Я не буду сейчас пока описывать как я представляю хорошее решение данного примера на разных языках. Моя мысль дня была в том, что ненужные с точки зрения кода рассуждения вероятно не нужны вообще и их наличие - недостаток архитектуры. А навеян пост продолжением чтения книжки про Руби и обнаружением в классе numeric метода, повторяющего блок N раз. Блин, оператор цикла - метод в классе целого числа. Зачем он вообще метод? "А потому!" - скажет автор, и будет по-своему, по-авторски, прав. Хочу тоже быть автором.

О высоком

В очередной раз удивившись потребности некоторых коллег испытывать к работодателю трепетное чувство верности, я подумал, что моё предыдущее объяснение этого явления не годится. Конечно, это спокойнее, но сила ненависти, которая обрушивается на усомнившегося в идеалах больше, чем объясняло бы сохранение душевного спокойствия или нежелания анализировать. Причём чем моложе собеседник, тем сильнее иррациональность чувства, что явно наводит на мысль об общности механизмов с другими человеческими инстинктами. А ведь скорее всего опять проявляется инстинктивное поведение. Человек - стайное животное, В стае интересы стаи важнее личности, отсюда и верность и самопожертвование. Отсюда же потребность принадлежности стае и депрессия от отсутствия таковой. Поэтому инстинктивные психологические механизмы, защищающие продление рода, переносятся на вожака. В бою вожаку надо верить, чтобы спасти стаю, даже ценой собственной гибели. Гены твоих выживших детей это запомнят. Может отсюда же и религия? Часто говорят, что человеку свойственно верить. И поэтому либо та религия либо другая. Я всегда считал это пропагандой, но сегодня задумался: может действительно свойственно?

Жгун

Замечательно мужик рисует. Лица получаются отлично. И детали. И написал в одном из постов, что ищет работу, только не web-дизайн и не фирменные стили. Да уж, конечно! С таким талантом надо чем нибудь дельным заняться. Весь этот web-дизайн, в принципе, как и все эти "фирменные стили" есть просто распальцовка и ничего больше. Вот смотрю на продукцию самой известной российской дизайнерской фирмы и ничего кроме распальцовки не вижу. Неудобная клавиатура за несколько тысяч, какие-то странно уродливые и неудобные дизайны, херня какая-то. А вот у меня под рукой мышь no-name. Самая приятная изо всех, которые видел. Купил за 12 баксов в несуществующем больше магазинчике. Искал, кто делал, так и не нашёл. Да и как найти, когда всей информации на бирке "Optical mouse, made in china". И всё! Нет, не надо идти в web-дизайн. Лучше книжки оформлять. Хотя бы и онлайновые.

Утиная типизация

Пост навеян чтением книжки про Руби. Язык неплохой, но, на мой вкус, немного пересолён объектной идеологией вкупе с ритуальным юниксизмом. Дочитал до утиной типизации. Есть языки со статическими типами, когда типы вычисляются во время компиляции (С, С#, Java etc.), есть с динамическими, когда переменная может содержать любой тип и во время компиляции он не известен и даже может быть изменён присваиванием значения другого типа (JavaScript, Python). Очевидно, что динамические типы почти невозможно скомпилировать эффективно. Более того, кучу ошибок невозможно предвидеть заранее и можно выявить только на этапе выполнения или нельзя выявить вообще. Зато интерпретаторы при этом получаются проще, сам писал, знаю непонаслышке. Честно говоря, я не вижу абсолютно никаких преимуществ динамических типов. Обычно к преимуществам относят то, что писать надо меньше, что я бы полагал даже несколько неприличным, поскольку оправдывается собственная лень. Собственно процесс печатания кода - это очень незначительная часть программистской работы. Есть очень удобный вариант статических типов - автоматические типы, когда тип определен, но явно не написан, а совпадает с типом выражения, которое присваивается. Он был предложен в новой версии стандарта C++, но, похоже, не вошёл. Зато элементы автоматической типизации есть в C# начиная с версии 3.0. var x = выражение; // Переменная x будет того типа, какой имеет правая часть. Это удобно для всяких итераторов и элементов коллекций, т.е. когда тип сложен и вторичен, например внутри цикла foreach. Но, тем не менее, это всё равно строгая статическая типизация со всеми её преимуществами. А "утиная типизация", которая декларируется в Руби, это из поговорки, что если некто крякает как утка, ходит как утка и плавает как утка, то это, наверное, и есть утка. Но это "наверное" и есть слабое место. А вдруг это утконос? Нельзя дать никаких гарантий, а потому надо постоянно и непрерывно проверять тип.

Рогоз

А таки действительно рогоз, а не камыш! Надо же, какое всеобщее заблуждение.

Corteo

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

Софт подчиняется закону Паркинсона.

К предыдущему посту. Причина в том, что софт подчиняется закону Паркинсона. Точнее, не весь софт, а разрабатываемый в "больших компаниях", т.е. компаниях, функционирование которых подчиняется вышеупомянутому закону. Иногда считают, что закон Паркинсона - шутка, типа закона Мерфи или закона бутерброда. Вот, Wikipedia так и говорит. Или путают его с одноименной болезнью. Когда-то это имя было вполне известно, но в последнее время я упоминаю его в разговорах и народ не слышал. Не хотят люди анализировать общество, скользкая тема. Так вот, это не шутка и не юмористическое наблюдение. Это именно закон, который работает точно так же, как и другие законы, скажем идеального газа, единственное отличие, что в качестве молекул выступают люди, наделённые свободой воли, а потому они делают газ не столь идеальным. Но в среднем, всё равно, один человек редко может изменить поведение сложной системы, а потому закон работает. Фактически, в обществе тоже есть силы и, мы, материальные точки им подчиняемся и двигаемся соответственно. Большая компания - это именно компания, где индивидуальные траектории уже формируют статистическое поведение и, как правило, если нет сильных внешних сил противодействия, закон Паркинсона вполне работает. Так вот, именно поэтому софт и заполняет весь доступный объём, и все прочие ресурсы. Он просто растёт до тех пор, пока не начинает встречать внешнее давление, направленное на его уменьшение. И давление это начитается где-то на уровне "стало работать хуже чем раньше". А растёт софт изначально потому, что писать новый код проще, чем рефакторить старый. И не только проще, но и спокойнее, меньше вероятность сломать. Вот он и растет пока давления изнутри и снаружи не сравняются, что почти в точности компенсирует закон Мура.

TGMLC = The Great Moore's Law Compensator

Взято отсюда. Картинка говорит сама за себя. Раньше софт работал быстрее - это не иллюзия, это так и есть на самом деле.

Прошлогодний кампинг на Sunrise Point.

Продолжаю разгребать прошлогодние фотки. Это июльские, когда мы "кампились" на Sunrise Point, Mount Rainier. Всего фотографий было сделано очень много. Запомнилось: мармоты, был даже один детёныш, они почти не боялись и вовсю позировали перед камерами; шикарные белые грибы, которых было очень много, мы их даже пытались сушить на костре; изумительные пейзажи и необычные, огромные масштабы; гора просто гигантская, это не описать, это надо видеть; дождь в последнюю ночь, когда я проснулся и обнаружил, что в палатке кругом вода, я на коврике, а вокруг меня плавают разные вещи. Было хорошо. Все хотим снова туда. Надо будет купить солнечную батарею, фотоаппарат заряжать. Думаю, за ночь зарядится.

Пишут же люди операционные системы...

Contiki is an open source, highly portable, multi-tasking operating system for networked memory-constrained networked embedded systems. A typical Contiki configuration is 2 kilobytes of RAM and 40 kilobytes of ROM. Contiki contains two communication stacks: uIP and Rime. uIP is a small RFC-compliant TCP/IP stack that makes it possible for Contiki to communicate over the Internet. Rime is a lightweight communication stack designed for low-power radios that provides a wide range of communication primitives and protocols, such as multi-hop data collection, multi-hop unicast mesh routing, and reliable multi-hop network flooding. Contiki consists of an event-driven kernel on top of which application programs are dynamically loaded and unloaded at runtime. Contiki processes use light-weight protothreads that provide a linear, thread-like programming style on top of the event-driven kernel. Contiki also supports per-process optional preemptive multi-threading, interprocess communication using message passing through events, as well as an optional GUI subsystem with either direct graphic support for locally connected terminals or networked virtual display with VNC or over Telnet. Contiki runs on a variety of platform ranging from embedded microcontrollers such as the MSP430 and the AVR to old homecomputers. Code footprint is on the order of kilobytes and memory usage can be configured to be as low as tens of bytes.

Весна на Snoqualmie

Вот прошлогодние майские фотографии, сделанные на реке Snoqualmie. Я люблю это место. А заодно я начал немного править свой сайт уже порядком заброшенный. Вот, сделал slide-show. Нажать Show в правом верхнем углу. Проверял в FF2x и IE6. IE7 дома нет, завтра на работе проверю.

Дикие черепахи

Вот такой зверь живет в местных озёрах. Сфотографировано в городе, недалеко от места, где мы живём. Черепаху можно увидеть на том же бревне в любой солнечный день.