Мой Блог

За несколько лет у меня накопилась куча железок, управляющих домашней сетью. Это два четверть-гиговых Netdisk-а, один NAS с полугигабайтным MyBook, роутер и ещё один дополнительный свитч. Из устройств есть web-камера и DVD плейер, умеющий показывать фильмы с сетевого диска. Есть ещё несколько внешних дисков с бакапами разной свежести, лежащие по шкафам. Зрелище перепутанных проводов и блоков питания приводит меня в ужас. Хочется немного уменьшить этот бардак, собрав диски в один корпус и тем самым уменьшить количество проводов.

Сейчас есть пара интересных железяк от HP. Во первых это MediaSmart сервер, работающий под WHS и во вторых MediaVault, который и по размеру и по цене тянет на половинку первого, и который работает под Линуксом. Первый основан на гигагерцовом процессоре AMD, второй на дохленьком полугигагерцовом ARM-е.

Почитал я спецификации и всё бы хорошо в первом, если бы не цена и не WHS. Как-то не хочется сервер под windows, мне надо, чтобы работало и с Mac-ом и с Linux-ом. Да и функциональный набор WHS кажется довольно неприменимым. Нет, совсем не вдохновляет.

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

Пробовал их кто-нибудь? Интересны отзывы.

Та же проблема, что и в анекдоте про свечки, существует в программировании и особенно в ООП языках.

Допустим есть у нас набор объектов, скажем драйверы разных графических адаптеров. И другой набор объектов, скажем графические примитивы: линии, окружности, многоугольники. И решили мы нарисовать одно на другом. И написали для этого код. Всё уже почти работает, но перед нами встала архитектурная проблема: куда засунуть метод? В 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. Но, тем не менее, это всё равно строгая статическая типизация со всеми её преимуществами.

А "утиная типизация", которая декларируется в Руби, это из поговорки, что если некто крякает как утка, ходит как утка и плавает как утка, то это, наверное, и есть утка. Но это "наверное" и есть слабое место. А вдруг это утконос? Нельзя дать никаких гарантий, а потому надо постоянно и непрерывно проверять тип.

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

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

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

К предыдущему посту. Причина в том, что софт подчиняется закону Паркинсона. Точнее, не весь софт, а разрабатываемый в "больших компаниях", т.е. компаниях, функционирование которых подчиняется вышеупомянутому закону.

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

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

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

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